Hacker News Reader

Comment by pbourke | Hacker News Reader

> Which is why it's so utterly toxic that corporate America runs on an interrupt driven system, with meetings sprinkled carelessly across engineer calendars.

I agree with this statement and your other points. I’ve noticed a more insidious variant of this behavior: the expectation of interruptions. Some groups have such frequent priority shifts and/or a culture of fire fighting or door knocking such that even with a relatively open schedule, one is dissuaded from engaging in longer stretches of work for fear of having it all go to waste when the next meteor strike arrives.

View on HN

I think you can blame "agile thinking" for that and the general laziness in product planning which is so typical of the last 10 years.

We went from recognising that requirements may change after planning to zero planning and telling developers what's the next priority for the day, day by day.

This lack of planning and product definition is also what drives the lack of documentation, which is another big problem in 2021.

I don't expect going back to waterfall but also not what's going on nowadays. Hopefully we'll bounce back in the middle at some point.

I don't understand why software architect isn't a position in any of the new startup culture tech businesses. The advantage of having an older, very wise and very experienced engineer whose job it is to document, plan and understand all the moving parts of your project would have been invaluable instead of expecting all the engineers who are stressed about hitting deadlines and chasing down memory leaks to do that work on top of their daily requirements.

> The advantage of having an older, very wise and very experienced engineer whose job it is to document, plan and understand all the moving parts of your project

The problem being. People don’t want to hear that it’s going to take them a while to get from 0 to 100%. They’d rather hear they can get from 0 to 99% in a day, then spend a month slogging through that last percent.

The people who do this job at large companies are called Staff or Principal engineers. One reason startups might be less likely to have them is that they are extraordinarily expensive.

And you can’t cheap out on the role. It’s also really hard to recognize the right kind of person for this without a somewhat Mature engineering team.

The wrong person in this type of role at a smaller company can things back significantly.

Yeah I saw that early in my career at a small company. Smart and charismatic guy in an architect role, impressed technical and non-technical people alike with his knowledge.

Now that I have more experience I realize he was more excited about cargo-culting big tech practices than about making sure our software was well-architected. We wasted so much time enthusiastically implementing his low-impact but technically exciting ideas.

The opposite can be a problem as well: a principal or architect who is stuck in their ways or not up to date on the platform will cause a lot of frustration and waste a lot of time. I've seen this unfortunately a few times: highly experienced and generally knowledgeable engineers who are disdainful of mobile platforms and don't feel they need to learn about the details and limitations of the system before pronouncing on technical designs (This especially applies to iOS for some reason IME).

Yeah, there's one principal DS at my company, and he's a net negative. I'm honestly amazed that they have hired him and kept him (which speaks to deeper issues with the company, unfortunately).

A bad principal/staff person has around the same level of impact as a bad manager/director, except it tends to cause more technical badness than social badness.

I agree 100%. I've been working professionally as a software engineer for almost a decade now. For the past 5 years or so, I've been focusing on improving my understanding of architecture. I don't really want to be a manager or in charge of too many people. I just want control over architectural decisions. My hope is that I can carve out a niche for myself where I am a senior member of a company(or my own company) who still gets to get their hands dirty.

That's because software architecture like that requires knowing what you want, planning, patience, and such. The "thought leaders" of the business are jittering in all directions, busy pivoting, imagineering, and generally behaving like any other particle undergoing Brownian motion. Holding course to something specific would require ... well, it's just not going to happen.

It's my pet theory that we have to go back 50 years and do waterfall right.

See http://bawiki.com/wiki/Waterfall.html

We do: we've identified this is the most important bug; work it till its "done" so we can't task-shift that work till its done. No daily (or less) priority shift.

I've experienced this professionally. It's super debilitating. At some point, the only thing that you are willing to spend energy on is preventing the last fire you're exhausted from just fighting from happening again. I don't know what I'd have done if I didn't have good support from my manager at the time. He cleared a lot of expectations of other deliverables out of the way, so I could stabilize the infrastructure. Now, I know enough to work the politics to give myself room to do this work, but junior me couldn't have done it alone without cracking.

I agree but I wouldn't call it toxic, rather "foolish".

"meteor strike" what a brilliant way to put it. Been struck by a few of those in my time.

Reply on news.ycombinator.com