How to Become a Great Software Engineer | Hacker News Reader

How to Become a Great Software Engineer

newsletter.techworld-with-milan.com

30 pointsmilanm08159 comments

The thing I hate the most about the tech industry is that there is very little correlation between skill and reward and because everyone who has an economic voice believes that there is a correlation, we get led down all sorts of crazy fickle paths littered with anti-patterns and overengineered tools...

And the narrative keeps changing randomly depending on which nerds happen to stumble upon a successful business case at which point they are given the platform to impose their technology ideas on everyone else... Nevermind that they had 100x the budget of an average company and solved all their tech problems via brute force and dirty hacks.

IMO, there was a time maybe 15 to 20 years ago when the software industry knew what it was doing and there was a concerted effort to produce optimal, maintainable code but it seems that most companies just gave up and software became cheap, fragile and disposable.

This list, as presented in the blog post, is a great list though. Succinct and to the point. And in fact, just how I went to become a hopefully decent enough SE.

There was never a time when the industry “knew what it was doing”. Everything you described was exactly the same 20 years ago. Nor is any of it specific to the software industry.

It’s just normal experimentation and churn, driven by capitalism chasing profit at the macro and individualistic drive for more influence at the micro.

Same as it ever was.

This is not just a problem with the tech industry. In society in general there is only a weak correlation between skill and reward in lots of places and the variance in outcomes is very high and is dominated by factors like the socioeconomic background of your parents, race, gender etc that you don’t control.

However since you don’t control those factors you are better off improving your skill, which you do control. Maybe later you will be put in a position of importance where you can make optimal decisions that end up widening the funnel and reduce the importance of those things by hiring and promoting the best people for the job and caring about good dev practise.

I’m not buying your idea that 10/15 years ago the industry knew what it was doing and cared about quality though. I’ve been a professional software engineer for 25 years now and software quality as a whole has always been dire. There definitely is a minority of folks who care about it as there always has been so gravitate towards them.

I feel you about this issue of skill/reward ratio. And I've kept meditating a bit for some reason. What came to mind now is that, for making it "work better"(improve that ratio) the software engineer could try to see himself as a bulldozer operator where he is the skilled one, of course, but the software he makes is the bulldozer. The reward is neither on them but in the outcome produced by the combination of them. How much material he could remove or push from here to there.

That's why the STAR method is necessary in resumes or in interviews for example. We're so passionate about software that we could be easily become myopic about results and forget to talk about what's the outcome of the things we produce and use.

15 to 20 years ago a lot of systems didn't have to be distributed, multiprocess, run in the cloud and deal with as much data. Of course there were some then, but the trend has moved this way.

Also, the leet coders have taken over, back then they weren't as influential.

15-20 years ago, you'd run a tightly-coupled monolith in a colo and do scheduled downtime every few weeks to deploy everything.

Everything was more error-prone and fixing errors could mean a physical trip to the colo or downtime in the middle of customers' workdays.

We probably have the same amount of seat-of-pants, spit-and-bailing-wire problem-solving happening today, but the problems have moved.

Worst engineer I knew was an L9 at Google. But he was brilliant. There’s no right way to be a great engineer. If someone tries to tell you there is, they’re full of shit.

Completely agree.

Could you expand on that a little? Did he not contribute as expected on projects, but he was a smart person. Or was his approach unconventional?

‘Worst’ in the original comment means —‘bad’ from the default perspective that is prevalent at tech giants (perfect code coverage, everything makes sense always — as opposed to allowing for freedom to iterate, rewrite, and create exceptional software that people find helpful and love).

He is extremely good at prototyping quickly (including things that can be quite complex — even with good code quality), building things people really want, and collaborating with users. Had he not come into Google via an acquisition, it seems unlikely that Google would have supported him and recognized his formidable talent (and I doubt he would have had the patience for Google’s typical pedantic code review process — I’m not saying Google’s code review culture is ‘bad’ but it can be extremely alienating to many gifted individuals).

Working with him has been an exceptional lesson in challenging my default assumptions about what being a ‘great’ software engineer can mean.

… and especially that there’s no one ‘right way’ — there’s just what works for some folks and what works for other folks. As you can imagine, although I can respect aspects of Google’s culture, I am strongly against the philosophy that there is ‘one right way.’

I interpreted your original comment to mean: he is horrible as an engineer but a generally smart person otherwise.

It sounds like what you meant is that he is a great engineer, but he doesn't satisfy certain qualities that would usually be considered requirements (or at least required at Google) for a good engineer?

Indeed

About 4: I swear by "dog fooding."

I've seen quite often that someone picks up a request (issue, story), and interpret its in the first way that comes to mind. That's natural, if only because users rarely express their needs clearly. What helps is using your product as a user would. Understand your users tasks and needs viscerally. That makes it easier to get a welcome result, and shorten the prototype-critique cycle.

The OP forgot an important point:

0. Move to the United States of America

If you miss that one the rest is pretty pointless, unfortunately. For example, in (at least most of) Europe you would be much better off studying blogposts titled “How to Become a Mediocre Manager”.

That doesn't logically track, given that one can become a great software engineer anywhere they have an Internet connection these days. It's probably good advice for maxing out your compensation, though.

Doesn't research show that remote work is bad for mentorship though?

If the best engineers move to the US for high comp, and working with the best engineers is the best way to learn, then moving to the US could make sense even if you don't care about comp.

> It's probably good advice for maxing out your compensation, though.

It is not only about how much you make, but how much you save.

Are you making a claim that non-Americans save more money?

I mean you can save more depending on where you live due to cost of living and income taxes.

You can live very comfortably in a low cost country with a $90,000/year salary and still save half of that.

You can only save up to 100% of what you make (good luck with that), but you can increase your compensation more than that.

Sure and you can save more in America too.

A lot of great engineers wouldn't be great engineers if you didn't offer them great pay. That's just how a lot of people work. Instead that talent would be elsewhere.

That's why more people don't become great engineers, though, not why people can't become great engineers. In order for the latter to be an interesting question we assume a hypothetical person who already wants to become a great engineer - which, yes, may be because of the money.

> Instead that talent would be elsewhere.

Sadly that’s not entirely true. Some still follow their heart, but end up as mediocre disgruntled engineers in dead end jobs. It’s very hard to fight incentives for decade after decade. When those incentives point towards working as little as possible it’s hard to be great.

I think it takes a fair bit of mentoring and working with great senior engineers. Harder to do without physical presence. The closer a junior sits to one of these persons the faster they'll grow.

Yeah. But end goal of engineering is to improve life. You have only 1 life. Europe >>> USA quality of living.

The win-win is to live in Europe but work for an American company as a software dev.

Not really because you'll still get paid a European salary. In fact that's really the worst of both worlds - European salary but American pressure.

Plenty of European devs getting an American salary.

Not in my experience. Which companies pay the same in SV and the UK?

That's not easy with the time zone difference.

That depends on how much you make in the USA. I doubt 300k+ engineers are going to accept 80-120k euros for the same job in Europe. I make around 100k USD working in Norway as a research scientist. I doubt I'm going to be able to increase my salary anymore than that in my current job. Maybe I could get more managing an industrial lab.

> Yeah. But end goal of engineering is to improve life.

Nope. The end goal of my engineering is to build meaningful products that improve other people’s lives.

But sure, with your attitude to work you’ll do fine in Europe.

The universe was created without my help.

Humanity survived till 21st century without my help.

I am sure the world will do just fine with me working in Europe instead of US.

I am sure it will do fine when I am dead.

I will focus on helping myself as the first priority.

Thanks.

That's out of the guide for becoming a well paid software engineer.

There are definitely career paths in Europe that mean you get to flex your engineering skills. They aren't always obvious, but they very much exist.

In my experience they are usually scattered one-off opportunities that are ver hard to build a career around. And if you’re that good it’s easier to just see the whole world as your target market, build a reputation online and work remote. But then you’re essentially succeeding despite of Europe, while everyone around you have comfy positions because of Europe. Quite a hard position to be/stay in, psychologically.

Fun fact: CS education appears to be something that America is genuinely rather good at.

>Researchers found that the average computer science student in the U.S. ranked higher than about 80 percent of students tested in China, India and Russia, Loyalka said. In contrast, the difference in scores among students in China, India and Russia was small and not statistically significant.

>Researchers also compared a smaller pool of students from top-ranking institutions in each country. They found that the average student in a top computer science program in the U.S. also ranked higher than about 80 percent of students from top programs in China, India and Russia. But the top Chinese, Indian and Russian students scored comparably with the U.S. students from regular institutions, according to the research.

https://news.stanford.edu/2019/03/19/comparing-skills-comput...

> CS education appears to be something that America is genuinely very good at.

Here’s an alternative hypothesis: America seems genuinely very good at incentivizing bright young people to study CS.

This does not match my own experience. Though my experience is about 15 years old, which may be a factor. I have met a large number of students with cs degrees in the US who never wrote a single line of code.

I looked through the study and I was not able to find the test they were given. This is the organization that makes them:

https://www.ets.org/pdfs/mft/comp-sci-test-description.pdf

The phrasing for the US number is different but probably semantics:

We also obtained assessment data on 6,847 seniors from a representative sample of CS programs in the United States. When it comes to the foreign countries the district term "tested"

The sample size is drastically different:

China: 678 India: 364 Russia: 551 US: 6837

Further Americans developed all tests.

It would be interesting if the reverse tests were done. Russia developed one test, China one, India one, Then the sample group from this test would take each one seperatly and with good time to rest (days) between tests. If the results were equal to this first study.

They might well be.

It's funny how you can focus in fundamentals and see all interviews focusing on frameworks.

And a not so obvious nuance:

The a perverse side of this is that the business reward there, to what extent is not inducing the (pseudo)programmed obsolescence of frameworks into engineer's careers?

But no worries, AI can take care of the details right?

Should be even a stronger case for engineers focusing on fundamentals and using AI as assistants on the details.

Isn't the TIOBE index more of an "engagement" index than a indexes "of popularity" A good designed language will perform worse than a language where people struggle and ask a lot of questions online? If I rant about java, because I love Csharp. Doesn't java get rated as more popular?

TIOBE doesn't even measure engagement, it's just outright useless.

For one example of its stupidity, Visual FoxPro, a proprietary language which has been dead for 8 years - https://en.wikipedia.org/wiki/Visual_FoxPro - is ranked higher than TypeScript.

For anyone looking for perhaps something a bit more relevant, StackOverflow has some nice surveys: https://survey.stackoverflow.co/2023/

Also, there are surveys by JetBrains: https://www.jetbrains.com/lp/devecosystem-2023/

While I agree 100% I do feel many of these points are frequently ignored by impatient people looking for tricks, gimmicks, and tools that solve for convenience opposed to solving for challenges.

As I always repeat:

Convenience (instant reward) is to humans, what light is to bugs.

How do I learn... Gitwill?

Full of outdated advice. Tiobe? SOLID? Come on, these were never really relevant, and less relevant now.

I'm not familiar with Tiobe, but completely disagree that SOLID is irrelevant. I consider it to be as relevant today as it has always been.

It's also fairly obvious and common sense stuff. I'm not convinced that thinking about these principles in the abstract is helpful at all.

> It's also fairly obvious and common sense stuff.

"Common sense" means stuff you "know" but most people don't. That's why some people try to codify and share rules for what works.

https://www.psychologytoday.com/us/blog/the-power-prime/2011...

Agreed. I've seen multiple people trying to follow solid and clean code producing terrible unmaintainable code. The codebase I've recently inherited has useless interfaces and wrapper classes for literally anything. I.e. a simple write to local storage in a flutter app requires 6 files/classes to get done.

It is painful reading "clean architecture" based code. It... just kill it with fire. The indirection and abstraction turns even simple problems into overly complex nightmares.

Reply on news.ycombinator.com