Hacker News Reader

Comment by mLuby | Hacker News Reader

> “Product-first” engineers are obsessed with using code to solve a user problem and they see code as just a means to an end.

> “Code-first” engineers are obsessed with the abstractions, architecture, tools and libraries in the code. Elegant code is the end.

Then aren't basically all professional software engineers "product-first" engineers?

Consumers or clients are the users to "product" engineers, who in turn are the users to "infrastructure" engineers. If the infrastructure engineers spend their time building elegant abstractions, tools, and libraries that don't solve the product engineers' problems, the product engineers will get their infrastructure needs met elsewhere (i.e. off the shelve, roll their own, or outsource) and the infrastructure engineers won't be necessary.

(I'm not arguing against infrastructure engineers per se, just that their primary goal isn't elegant code.)

View on HN

I think it has a lot to do with motivation.

Some people are more motivated to solve the business problem. They may accrue more technical debt in exchange for important features and increasing revenue.

Some people are more motivated by clean, well documented, DRY code. They are probably going to fight to refactor parts of the codebase to prevent losing revenue.

Most people are probably somewhere in between.

That's an improvement on the article's classification. I'd say it's "make the change now; clean up later" engineers vs "clean up now so the change is easy later" engineers. Too much of the former and productivity grinds to a halt under all the tech debt. Too much of the latter and there'll be zero new features shipped. A balance (ideally within each engineer) is ideal.

This pretty much sums up the challenges I've been facing the past week

This seems kind of like saying "some people are motivated by sleeping, while others are motivated by eating" - every software engineer in the industry is going to do both. There's one type of software engineer, and it's someone who juggles multiple competing constraints. You meet product needs quickly using a coherent and well-designed platform; you build a platform in response to real customer needs. It's a silly dichotomy, because there's always a point when product-focused engineers need a platform, and when platform-focused engineers look for customer impact.

This is what a product-focused engineer would say :)

There’s definitely a difference between the people who are more interested in the results of programming vs. the people who are really interested in the craft of programming as a process. They both end up having to think about product questions, but they tend to find their way into different parts of the company: the product-focused engineers are always working on splashy new features while the craft-focused are generally behind the scenes trying to figure out a way to make the DX of the codebase better (and sometimes even being called “architecture astronauts” as a result).

I'm usually the most platform-oriented or infrastructure-oriented engineer on my team. I consistently push for refactoring, test coverage, observability, automation, design sessions, and good documentation. This week I've been adding load shedding and backoff to things, rewriting some old tests that were disabled for being flaky, and rewrote a gigantic fanout query to use a task pool.

That you think I sound like a product engineer when I've been wearing the "I wish we had a real SRE" hat all week is illustrative of the original point: they're not categories that engineers conform to.

And you really need everyone in your group to be the same type or you will have a lot of butting heads. I was once contracting on a project where I was building code to solve urgent business problems. By necessity of the timeline, the code was ok but not perfect.

Then they brought on a new manager, who immediately ran all my code through a linter and told me to stop all work until the linter came up clean. I told him that I was hired to make working code that solves an immediate problem, and he told me my services were no longer required.

I found out later the project was quickly moved to another team because his team was unable to meet the tight timelines.

That's the difference between process-oriented and result-oriented thinking. I've also heard the two extremes being referred to as "tool-worshipping fools" and "rule-breaking fools".

Organizations tend reward process-oriented thinking regardless of whether it succeeds or not, and results-oriented thinking only if it succeeds.

>Organizations tend reward process-oriented thinking regardless of whether it succeeds or not

I'm not sure if my experience aligns with this

This seems incorrect. The archetypal process-oriented professional in my book is the money-making poker player.

In poker, you cannot control the result of any hand -- not even the result of a week's play. To achieve long-term success, you must have a good process for your playing, and not be influenced by the results.

A good process sets you up for the best chance of success, but it cannot guarantee success. If you start to adjust based on results (and not deeper changes to the causal matrix -- these are process-informed changes) you'll do worse. Edwards Deming called this "tampering".

The same thing applies, of course, in business. The greatest process will produce bad results if you're unlucky with uncontrollable external factors. A bad process can by chance produce good results if you're lucky with uncontrollable external factors.

You cannot judge a process by its results in individual instances alone. Judgment of a process must be made in terms of theory, repeated experiment, and long-term tendencies of the outcomes.

And, as in poker, any long-term successful business is process-oriented. They carefully build processes that set them up for greatest chance of repeated success.

Any results-oriented business has -- by de-emphasising the process -- no way to influence the outcome. They are "driving on the highway by looking at the centre line in the rear view mirror" as someone put it.

Theory and process is the only thing that can tell you anything about future results.

I strongly recommend reading Deming's The New Economics.

Linters, Test Coverage, and Code quality reports are amazing and important. But these things don’t affect your customers directly. I think some engineers like spearheading these types of projects because they are safe to implement and easy to understand.

I see where you're going with this, but I think about it a little bit differently. Product-orientation and infrastruture-orientation are two different skill sets and professional software developers should have some development on both axes.

I have worked with developers all over the map on these axes and I think the fatal combination is someone who spikes on one axes but ignorance or even active disregard for the other. The failure modes look very different though. The "product-only" engineer quickly whips up something that satisfies their user's need, but over time the code becomes sphagetti that is buggy and painful to modify and the users are unhappy. The "infrastruture-only" engineer makes a puristic system that seems impressive from a technical point of view, but interfaces poorly with the customer's problems. Customers either have to go through contortions to make their problem fit into the architecture of the system or they just move on and find something that is better suited to them.

So, in your terminology, a software engineer who is bad at programming is a "product-only", whereas a software engineer who is bad at business is "infrastructure-only"?

If so, why invent new terminology when we have the perfectly fine description "software engineer who is bad at business"? Isn't it bound to confuse more than it helps?

Why do we even go into negative descriptions?

Why don't we go thinking about people strengths and think how we create a team that is composed of people with different strengths?

Manager will have to make sure he makes it clear in the team that:

Joe might not be whipping perfect code but he is good at figuring out users vague requests and putting those into action.

Jane might be obsessed with her language of choice and does not like vague requirements, she likes something like we are having 20 requests per second make system to handle 50.

You don't want to describe people as "bad in something" because that is not productive. For a manager that should be obvious.

But even if someone is working in a team, describing colleagues/projects/workplace in negative ways is bad and not productive. While yes there are instances where it is bad and people should call bad things out, but most of what I see are mere annoyances that one can gloss over.

For the same reason I talk about security weaknesses, and not security strengths: pointing out a weakness is the first step to fixing them.

Even if you have no interest in fixing a weakness, it is absolutely essential that you're aware of it, and can engage in compensating behaviour.

What I see in "software engineer who is bad at business" is that is broad and not useful. We can discuss specific flaws with specific person and think about course of action to fix it.

Telling someone "you suck" is not first step to fixing anything.

Just like laughing someones system has so many holes as Swiss cheese.

You want to be specific like you have an XSS here and here, those are steps to fix it.

Agreed. I don't think everyone can be great at everything. There are some basic levels of competencies that are required though and, most importantly, people need to be able to respect the strengths of others that don't align with their own. My own examples were driven by working with developers who were actively disdainful for people and ideas that were not on their single axis of focus, which was bad for the team and for the product.

The first example isn’t a software engineer. The code is a spaghetti mess because the system wasn’t engineered - there are no design documents, because the system wasn’t designed it was just hacked together. There’s no memos describing why certain decisions were made.

The second is, ironically, usually the same, but instead of a lack of design there’s a lack of requirements, which is even worse.

That part caught me too. I'm not obsessed with either one. People pay me to make computers do what they want them to do.

Can we start by not calling people lacking engineering degrees "engineers"? Nothing wrong with being a "developer" but everything wrong with being a CSS jockey who gives them self an extremely inflated title. Exceptions can be made for CS degree holders in my opinion.

I don't hold an engineering degree myself, so I am just "programmer". I still make more than most engineers, so why the fuss?

Because computer science is not an engineering degree, and (at least in the states) professional engineers are required at a minimum to hold a four year degree in an accredited engineering program, work under a certified engineer for a period of time, take an exam, etc. While this is for literal physical engineering, there is not an appropriate parallel for software engineering. There are people who hold doctorates in computer science that cannot build functioning software. And it’s not expected that they can — CS is not an engineering degree. If mathematicians were commonly employed like software engineers, they may find themselves adopting a Mathematic Engineer, but that doesn’t mean it bears any relationship to an engineering degree, let alone any degree.

In addition to that, the title is more descriptive of what other employees should expect from you. A programmer is a typist, tasks in results out, no creativity or problem solving expected. Developer creates something new so a little more creative. Engineers engineer stuff they plan and make things work. Architect strictly plans. I don't say thats what they do but a lot closer to what people expect.

> While this is for literal physical engineering, there is not an appropriate parallel for software engineering.

What you have described of an engineer applies to software engineers in Canada. There exist accredited software engineering degrees, some of which may be held under a computer science major with a further specialization in software engineering. There used to be a PE in software engineering in the US. So a parallel for software does exist.

Given that there is precedence for licensing and there exist programs attempting to focus on educating those who need to build systems, why is there such an aversion to hiring those graduates and following those processes? Do they produce worse software? Is there no need because of agile and move fast and ship things?

For one thing, there's absolutely no standard on the titles and they mean entirely different things at different companies.

Company A: A developer just installs and configures off-the-shelf software along with plugins or modules to develop a solution, but they can't really program. A programmer does all the hard work of planning and designing, understanding the system, creating custom code to solve problems, and instructing the developer what off-the-shelf parts to use and how to configure them.

Company B: A programmer just follows instructions from a developer to churn out code, they don't have to solve problems or understand the system. A developer develops the solution, from planning based on requirements, to figuring out the whole system and coding structure and giving instructions to programmers.

Same titles, opposite roles.

Then you get to Comp Sci vs Engineering discussion. That's a whole other can of worms.

Sure, someone might not be doing Big O analysis of a system or whatever. But how often do you really need to outside academia? In a lot of jobs, most performance problems are caused by a few things like cartesian products and/or bad indexes in a database query, or some code that loops doing a query for each thing to fetch data then processing the data, then looping to do additional queries to update the database (when the whole thing could be done with one query, at least with a minor change to the schema), or loops that call a network request for each item. You don't need a detailed theoretical mathematical analysis on a graphing calculator to recognize and solve things like that.

Another is an open endpoint - sure it might not do anything problematic from a security standpoint, and if you set up another system to call it once a day or once an hour it'll be fine. But what if some outsider sets up a system to call it once per second, or a botnet that calls it several times per second? Again, you don't need any complicated formulas to see that that will be a problem.

So sure, there might be some difference in attitude/approach of a comp sci person vs an engineer vs a developer vs a programmer vs an architect. But companies don't know the difference and just give you whatever title they think sounds good. As a pragmatic software person, I don't care what they call me; I just concern myself with whether I can recognize and solve (or better design to prevent) the problems.

Not even going to mention the credentialism regarding degrees.

For a long time, like you, I called myself "programmer", which to me encompasses all of it. But it turns out some business people take a very different view of the terms, so now I just go along with whatever title they want to give me. As long as I can handle the job well, that's what I am.

No, I don't think so. You don't need to be strictly in an infra-oriented position to do infra oriented work. The most common example is the proverbial senior developer setting stack standards for their more junior team (despite being in a role that is largely oriented towards shipping actual products).

Conversely, one could be a product-first infra person, who ships widely useful tools but whose code may be of questionable quality (e.g. someone might duck tape together some mission critical CI pipeline w/ python and bash and no tests)

I would not say obsessed. Instead I divide engineers to implementors (people who are masters of using frameworks/libraries to implement features, but are not capable of writing one) and developers (people who can write a framework/library if that is the ticket).

But yes, there are lots of implementors around and very few developers. We currently try to hire a developer and that is not easy.

Reply on news.ycombinator.com