Hacker News Reader

You nailed it in the first sentence - businesses don't need developers, they really need problem solvers - but we often don't get a seat at that table to turn around a problem before it lands on our desk as a request to code some poorly understood idea someone had.

1) Identify the problem - it invariably isn't to do with code but a combination of time and cost. 2) Can the problem be solved without a line of code, such as changing the process and removing the issue that way? 3) Is there an off-the-shelf application, software or component that will solve the problem. 4) Maybe you do need to code something.

We are also all too quick to just dive straight in at (4) because that's what we identify as, that's what we enjoy and unfortunately what we get paid to do rather than getting paid to think, advise and value-add.

Some ideas that look poorly thought out are in fact pretty good, just different from what we would do ourselves.

In my experience it is a key skill to objectively evaluate ideas that are different from my preferences and accept those that are good enough, but not use my preferred way of doing things. This is a quick path to get a seat at the table and getting your opinions heard. My 2c.

A perspective worth considerably more than 2c. Made me think.

I agree with your sentiment and yes, a workable solution is always the best solution. Idea was probably the wrong word, it's the highly vested, fully formed solutions that I've had issues with.

Also, in saying that, I do believe domain knowledge is far more valuable that programming chops, and not understanding the domain to be able to translate that into an application process is worse that someone with domain knowledge trying to come up with how it should be coded.

Some of the best projects I've worked on involved a lot of sitting and drinking coffee with the domain expert.

I think the problem is that getting the information from the domain expert and then running and programming with it is doable, but the domain expert cannot ask you for advice on programming and then build an application (at least not in the same timeframe).

> Some ideas that look poorly thought out are in fact pretty good

The only times I've ever found that to be true is when there's other details available that I'm not aware of. Business constraints "everyone knows" about but aren't documented anywhere, for example. Decisions made in a meeting that aren't communicated out, meaning, essentially, that you only are given a portion of the problem and request. This gets back to the 'seat at the table' concern above.

The 'seat at the table' is far more related to interpersonal/political skills than technical ones, but can be chicken/egg in some places.

My opinion is certainly skewed by my personal experience, so take it with a grain of salt.

That said, engineers are a highly opinionated bunch and a group of 5 will have 5 different personal preferences. But they are smart and will quickly recognize an objective opinion that is not hard-driven by personal preferences. Folks with good technical judgement who are willing to accept a different approach quickly become a highly respected member of the community. They frequently end up with more tables offering them seats, in a technical expert role, than they care to occupy.

This is one of those places where strong opinions, loosely held should be applied. And I can imagine those people getting more invites simply on the basis of possibly being more agreeable to interact with.

Programming is an abstraction (a perspective on what the computer is really doing) that is very much shaped by the tools we choose to use. Meta-religion is probably a fair way to describe it, and can be every bit as divisive in some circles.

> we often don't get a seat at that table to turn around a problem before it lands on our desk

This. We don’t get to change the problem after the fact either.

Has anyone ever seen a medium-to-large-sized company, in any industry/vertical, that's solved the "[Engineers] often don't get a seat at that table" problem?

Anecdotally, because I've brought up this issue a lot, I've heard many responses from bother sides. From some engineers, not in the room: "I would never want to be in the room, because then I'd have to work with those people". From other engineers: "They'd never want us there, we're just resources to be used."

From the non-engineers who are in the room: "we didn't know you wanted to be there, of course you're welcome", or "we didn't want to interrupt your work for such a high-level meeting".

I find that the reason for exclusion is either incompetence (in which case, get out), or a lack of awareness that certain engineers are exceptional sources of opinion, in those rooms.

But I've never seen a culture that's pushed engineers into those strategy meetings; it's always been opt-in rather than opt-out. (It's always opt-out for the product org).

In my experience I don't often hear: "They'd never want us there, we're just resources to be used."

But: "Damn those stupid meetings again, wasting my time."

It is like a lot of developers don't consider meetings part of job. I am currently less and less into actual typing of code and much more into understanding what others are trying to accomplish.

As engineers, we are spoiled in that we are accustomed to (1) navigating high signal:noise ratio environments (2) systematically improving the signal:noise ratio in environments where it’s poor.

On (1), many corporate meeting rooms have terrible ratios, and so they intuitively feel unproductive. On (2), it’s much easier to improve the ratio in code than it is in words spoken by people.

It requires a lot of patience, but in the long game, engineers do improve that ratio in meetings and strategy discussions, and the company benefits from it.

My theory is that most engineers are not interested in playing the long game, because (1) it’s not as fun (2) they don’t plan on being at the company on time scales where the investment will have been worth it.

While I personally don’t emulate their behavior, I think the developers you describe could conceivably be acting perfectly rational for their career goals.

We all have to start watching SNL Nick Burns as part of CompSci education maybe.

Yeah, the advice that you should spend more time on understanding the question rather than figuring out various solutions is right

That were exactly my thougts when I started reading the article. If you have a great developer that will leave on the first sign of trouble, maybe you're better off with an average developer that will understand the business needs and will "averagely" do it's part in solving whatever problems exist.

Most businesses don't need "great" developers. They just need to get the work done.

Getting someone who is really skilled can of course be beneficial but it certainly has the problems of retention, things like providing interesting challenges, high compensation. Not all businesses have deeply interesting technical problems. That's fine. There is plenty of use for the wide parts of the bell curve fpr both businesses and developers.

Yep. I once worked at a manufacturing company. Their clients sent order information via an FTP server. The orders were formatted as flat files, aka just simple text files. I had to create code that painsakingly looked through each format and imported it into the new ERP system. Every vendor was different in each flat file. I'm sure some had similarities, but abstracting the logic was more dangerous in this case.

A lot of business software is boring. It does not take skill to do. It only requires someone to know a handful of tools and be willing to put in the time. So my advice to non-FAANG developers: if you want to make development your career, learn to be bored. Still work on marketable skills, learn new languages, etc. But remember that not every task will be an interesting new technical issue, it's probably going to be something you've seen a hundred times before.

>So my advice to non-FAANG developers: if you want to make development your career, learn to be bored.

is life at FANG really that different tho? Can't imagine that everyone is working on exciting stuff all the time. Would appreciate if someone could enlighten me.

Well somebody has to be the one to annotate a million private and public SDK’s with @nullable !!

And once you’re done with that, there’s a whole load more refactoring for the latest language update!

I can speak for only one of the FAANGs, but the work I do there is definitely the most exciting to me personally from all the companies I've been at. There are challenging technical problems that require discussion with other engineers to design a solution. In most companies I've been before the challenges were mostly organizational and I had to deal with all of the "agile" crap to please PMs and managers, while the actual technical work was boringly easy.

It's not always rainbows and butterflies here either but I do feel much happier with the work I do here.

The only difference at (most of) Google is that you would use grpc instead of ftp and protobuf instead of txt.

> A lot of business software is boring. It does not take skill to do.

I guess it depends on your definition of "skill". ERP systems are complex, full of problems, inflexible and managed by bean-counters with "battle-axe" personalities. If you look at the work holistically, it does take skill and experience. There is a lot of room for improvement in these systems but the problems involve people as much as they involve technology.

Maybe if you have a lot of money lying around. But in my experience this enterprise forms of development leads to ballooning team size and mediocre software.

The same software build by a small team of experts would cost both less, and lead to a high quality result.

I agree with this. It's probably better to have an average, good developer who is reliable and consistent, than a brilliant developer with risks of overengineering a product or system, burn out, poached, or seek new pastures.

It might also relate to intellectual satisfaction. A "great" developer could be hungrier in that sense, that they need worthwhile projects to challenge their skills - and may get bored more easily.

That's been my experience as well. I've worked with some clever and / or highly effective (= fast) developers, but in practice the applications ended up overbuilt (like the tech lead who spent six months under water, only showing up to the office maybe once a week, while he was building a framework), or applications with a lot of features but missing the foundations (e.g. microservices architectures but with no end-to-end tracing, testing, interprocess communication standards, logging, etc).

These are not the qualities of an expert according to Dreyfus’s model (As referenced by the article). According to the model, as you gain skill you also gain the capability to bear responsibility. A beginner programmer can be responsible to program to a clear spec / wireframe. A senior dev can be responsible for making the client happy. It’s not obvious to a beginner, but those are very different tasks.

If you spend 6 months working on the wrong thing, you aren’t taking responsibility for delivery. It’s a mistake that most smart programmers seem to fall into at some point in their career, when they’re still learning. It’s a classic sign for me of a mid level developer made into a tech lead before they’re quite ready for the role. I’ve seen that happen way more often than I’d like.

If your tech lead is making mistakes like that, your team is operating without a real senior dev at the helm. That’s not insurmountable, but don’t mistake that sort of thing for real expertise.

>like the tech lead who spent six months under water, only showing up to the office maybe once a week

Do these folks face any consequences for behavior like this?

Why would they? it’s still cheaper to have a talented dev overbuild a framework than it is to find bugs in the code of someone who didn't understand the problem they're solving.

When I was starting my career, one of my first jobs had two clear career paths for "programmers": Business Analyst and Software Engineer.

A Business Analyst focused on figuring out business solutions and constraining those to realistic technological limitations.

An Engineer focused on architecture and implementation.

Seems to me you just chose the BA area of expertise... there is a lot of value in that, but the Engineering side is just as valuable in my book as if you have great ideas and plans but the actual engineering is poor (and vice-versa), your company is going to suffer.

> More than once I have seen a peer or a whole engineering department of brilliant people going down a technical rabbit hole for weeks for intellectual satisfaction, where instead I will just take a step back, walk to the manager and try to work a different take for a solution that can be implemented in a few hours/days even if the business goal is slightly moved.

What do you do when management doesn't want to move their business goal? Now you look like you're incompetent and incapable of just doing the damn thing they asked for.

Asking rhetorically, not as criticism, but because I've been there and it fucking sucks when the people who aren't working on the problem think they might have a better understanding of the big picture than they do.

Ever considered that everyone is doing everything all wrong and you're just feeding into the frenzy?

That's where I've come as a professional. I couldn't give a fuck any more about anyone's problems and I've learned that it has everything to do with creating pathways for people to communicate.

People are difficult creatures and academia has made us into basket cases unable to tie our own shoelaces without help from someone who will evaluate us and dangle a carrot in front of us for the effort.

How about getting over yourself with your corporate lorem ipsum and use the technology at your disposal to fix this dumpster fire of a planet we've made for ourselves?

Software isn't going to fix the planet. That was all bullshit to make rich people feel better about taking most of the USD funny-money. Strong centralized planning in the form of a functioning government, structured around resilience, erring ever on the side of direct democracy, fluid representation, and lifting economic victims over perpetrators in power is what will fix the planet. It's common sense. The software will simply be reduced, so people stop building the same thing over and over: it's stupid, always has been, and the cries for more devs were always just to make it cheaper and more disposable.

No! It's all the knowledge we've amassed that we hardly put to any use beyond milking it for entitlements.

Who ever speaks about our duty to our fellow man and the giants whose shoulders we stand on?

I blame a lack of classical education on this performance based meritocracy that's become a runaway train with no ethical brakes.