Hacker News Reader

Comment by astatine | Hacker News Reader

I was inspired by the AOSA many years ago and I had studied (and held out) as an example the Apache architecture (about 18-20 years ago). It is indeed a pity that so many younger software engineers really have no idea of how heavily used real-world systems get built. Nor do they understand all the various tradeoffs and corner cases that need to get handled to make products work well in real life.

Building Apache from source (including a few key addon modules) and configuring it to work for a small set of tests was step 1 at my organization then. Those successful at this would then get into the source itself. Fun times!

View on HN

> It is indeed a pity that so many younger software engineers really have no idea of how heavily used real-world systems get built. Nor do they understand all the various tradeoffs and corner cases that need to get handled to make products work well in real life.

Isn't that a hallmark of a junior engineer :) ? If you're trying to achieve deeper technical depth (which takes time), it helps to be a part of an organization that rewards said technical depth.

> it helps to be a part of an organization that rewards said technical depth.

I agree. My previous job wanted to employees to finish work ASAP. There were no incentives for quality. Performance was judged on the basis of how fast one can push things out irrespective of quality. As a result there was lack of engineering.

Not only that, but those types of organizations are also the ones that are likely to tell experienced engineers that they are "overqualified" for the job because they want more juniors that won't push back against harmful practices.

Only for a while. After a number of failed ‘initiatives’ someone at the top is bound to start asking questions.

Unfortunately deep technical depth is unwarranted and unwelcomed in many organizations. In fact you repeatedly get told that "the customer doesn't care about your code". At the end of the day adding yet another 'if' condition to patch up things is what is usually appreciated.

> I once worked at a place where we had an endpoint on an application taking a long time because of a weird DB query, like 12+ seconds to query a few hundred rows. Was pretty much told if we didn't figure it out today it doesn't matter, we'll ship it like that.

Even worse, writing code fast instead of good usually leads to catastrophic events. The solving of those problems (usually late in the evening or the weekend) will be seen as heroic and rewarded. But it’s just stupidity.

Reply on news.ycombinator.com