Live data from Hacker News

What I’ve Learned in 45 Years in the Software Industry

bti360.com

241–250 of 371 posts

Re: What I’ve Learned in 45 Years in the Software Industry

#241

Earlier quoted context omitted.

Bashing and shit talking software engineering profession is welcome on HN?

Let me paraphrase the original comment to make my next question easier to answer: Effective software engineering in a business context requires awareness of business needs. Which part of that is “bashing and shit talking”?

How about,

Effective software engineering in a business context requires awareness of business needs as well as the technical skills to address those needs.

Re: What I’ve Learned in 45 Years in the Software Industry

#242
post #231

> Clean, understandable, and navigable code and design It's interesting to see "navigable" in here - I've struggled to articulate in the past this problem and I think this nails it. We often see simplicity come at the cost of "navigability". All the configuration by convention frameworks have this problem particularly heavily. I'm often at a complete loss to trace the mechanics of what is happening in things like vue…

Webpack is one of my absolute favorite tools. It's easy to reason about and a pleasure to use. It absolutely checks the "navigable" box in my book.

However, it got constant flack (esp. here on HN) for being too complicated. Apparently asking a dev to spend a day learning the tool before getting started on a new project was too much to ask. Now the best practice is to use a meta-tool like vue-cli or react-scripts to abstract away Webpack, trading navigability for simplicity. Simplifying complex tasks requires magic and good luck debugging when your magic incantations don't work as expected.

I totally agree that navigability is super important and I wish I knew how to better emphasize it in my projects over the "batteries included" approach that has the best marketing.

Re: What I’ve Learned in 45 Years in the Software Industry

#243

Earlier quoted context omitted.

My experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality. Maybe it's different when you interview at a FAANG company though? I imagine FAANG recruitment is a merciless sausage machine.

> My experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality. I'm growing further and further away from this mentality in hiring because the sad truth is most of those folks who come in with "quirks" lack maturity. To me, quirks…

Personally, I don't really care how anyone dresses. (Oh, up to a point. One of the jobs I had evolved to, "No tube tops, bicycle shorts, or French maid outfits". The last two involved one senior hardware support guy.)

But the other things? Oh, yeah. I've worked with (or attempted to) people like that, and I won't do it again. The first time a technical difference of opinion turns into a suicide threat, I'll just clean out my desk on my way out.

Re: What I’ve Learned in 45 Years in the Software Industry

#244

Earlier quoted context omitted.

There are other paths at Google than upgrading to mgmt, but all of them involve "cross-team collaboration" and other quasi-political (with a small-p) aspects. Actually just writing code at Google is, from my experience, a small part of the job and not rewarded. The faster you get out of writing code and get into designing and delegating it, the better you're off. Sucks if you don't like it. Coming up with a way to re…

I've seen people from small companies playing the tech lead or manager roles, move into google as "Senior Software Engineer" or whatever equivalent - basically writing code again. And the reason is in your edit. In fact a lot of the "hot shots" at small startups that play nice with the boss and can wrangle Jira but were actually excellent coders - can't do the politics at the big companies. Part of that is that the b…

[deleted]

Re: What I’ve Learned in 45 Years in the Software Industry

#245

Earlier quoted context omitted.

> not dressing appropriately for an interview What is "dressing appropriately". I wore a suit to my very first interview for a dev position and very nearly didn't get the job because they were worried I wouldn't fit in (luckily I was able to explain that I don't usually wear a suit). The other ones in your list, sure. But I don't think those are what people typically means when they talk about quirks.

> I wore a suit to my very first interview for a dev position and very nearly didn't get the job because they were worried I wouldn't fit in Yeah - I hate this. I had people at my last position give candidates negative points because they wore a suit and I went $%&#ing ape. In positions that I've held in the past it's been the appropriate action to wear a suit due to heavily corporate environments, and I see it as 11…

As an aside, the haircut and shave are optional. But be careful, you may end up with a nickname like "Q-Tip" or "Voltan".

-- "Sasquatch"

Re: What I’ve Learned in 45 Years in the Software Industry

#246

3. Simplicity Fighting complexity is a never-ending cause. Solutions should be as simple as possible. Assume the next person to maintain your code won’t be as smart as you. When you can use fewer technologies, do so. This is the one I appreciate more and more as I age. Because frequently, I'm the next person looking at my own code. And there's no better gift to your future self than well-written, easy-to-understand c…

I somewhat disagree with the way he connects simplicity and cleverness. I once had to explain the behavior of a particular subsystem. It was governed by a bunch of simple rules, but their combination created a complex behavior. This was similar to social insect colonies, where components (eg. ants) are driven by relatively simple rules, but the whole system exhibits remarkable "emergent behavior". What takes cleverne…

Something Alan Kay has talked about multiple times is how sometimes raising the complexity of your building blocks slightly can reduce the overall complexity of the system. He uses the example of modeling orbits with circles vs ellipses. Ellipses are more complex building blocks, but yield an overall much simpler model for how orbits work (not to mention the correct answer).

Re: What I’ve Learned in 45 Years in the Software Industry

#247

This is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems.…

> I think this is a corrosive aspect of the perf/promo process at many FAANGs

Disagree on personal experience with two of the FAANG Cos I have worked for. A person content in their position, performing/delivering as expected can (and many do) coast. There was little to no pressure from these firms to "move up or move out".

Re: What I’ve Learned in 45 Years in the Software Industry

#248

This is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems.…

At FAANG there's always an IC track and management track. Additionally, promotions are almost always lagging, meaning the individual needs to performs at that level for some time before being promoted.

Re: What I’ve Learned in 45 Years in the Software Industry

#249
Regarding simplicity, I’ve observed the following about design. Usually, designs become more complex with time. If the RATE of complexity increase exceeds a certain level, the design is crap and that approach needs to be scrapped. Occasionally, a design gets simpler as one goes forward. THOSE are magic!

Re: What I’ve Learned in 45 Years in the Software Industry

#250
post #6

Something that I find interesting is that career advice coming from professionals having many years of experience focuses almost exclusively on the people aspects and not the technology: communication, trust, teamwork, documentation, clarity. The advice is clear, precise and honest. This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, d…

I think there is the effect of weeding out people with strong technical skill but low focus on “people” skills (not talking about jerks, just people who don’t play politics).

Honestly I don’t think it’s a good trend or that it’s unavoidable.

We shouldn’t look at the world today and take it straight as a lesson of what should be done. A bit like saying being gorgeous, extrovert and good negociator is the key to success, it sure can be but it shouldn’t be the goal of everyone.

Post reply on HN