Hacker News Reader

Comment by anyfoo | Hacker News Reader

I did not feel super sympathetic when reading the breakdown of percentages (with only 10% "actually writing code"). Yeah, those specific percentages were a bit egregious, but working on a big project it's not uncommon at all to spend more time thinking and talking things through than to actually write code. There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually engineering.

This however:

> And the worst part is, I feel like the product we were shipping was really bad. It was slow and kludgy. It was the opposite of the qualities I value in software products. I didn’t feel like I was adding any value, and I was miserable.

Yeah, there is absolutely no excuse for that. And if that is the case about the product you're working on, what I said just before about "enjoyable engineering" will never apply. Good for getting out of there.

View on HN

>There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually engineering

In my experience there is almost no correlation between complexity of the project and time needed to do 'non-technical' work. Quite contrary, the most complex things I did as a dev required me to do a lot of coding - to prototype, to experiment, to load testing and so on.

And at the same time the easiest project in the larger corporations required me to write down design docs for trivial stuff and spent months in meetings to 'align' with people, who don't have time to even read your design doc, but want you to have bi-weekly meeting about it.

So no, I don't buy this excuse anymore. Unless you are building space ship or do very unique work, there shouldn't be any need to spend 80% of your time in non-strictly-technical work.

I fundamentally disagree with the notion that design and discussion, of often very detailed technical aspects, is "non-technical work" of any kind, or that sitting down and writing code is the only "technical work".

Yup. Once you're doing staff-level IC work, most of your technical work is talking.

Maybe so, so long as we disagree with the notion that that the most senior engineers, the ones who are having "discussions" and making technical decisions, should not have to be active in the code, work with the development teams, and have a deep technical understanding about it works today.

They don't have to have the highest commit counts, but if they're not the ones the rest of the development team look to for help solving critical bugs and advice about new features and designs etc., then they have no business evaluating technical concerns.

I mean, of course. That's part of the job: you can't search for multiplier effects without knowing what they are.

Okay, just making sure. I've had experiences where people making technical decisions hadn't written a serious line of code for 10 years. Maybe they used to be good, but they wound up resting on their laurels. They frequently do make great decisions. Some can just muddle though things if they listen to the real technical people, the ones who are incapable of even that are a disaster.

Doing design and discussion without writing code just feels like deliberately hampering yourself. Code is the best language we have for describing things unambiguously! Weeks of plain-English discussion can save you hours of prototyping.

That works in mostly self-contained projects. As soon as you interface with other teams, or even hardware that is still in development, you better make sure that everyone is aligned on the critical details before plowing ahead. Otherwise it can get very expensive (in terms of time, money, and motivation) to prototype yourself into a corner.

Just this week I witnessed some team having built feature without consulting another critical team, and now it has to be reworked and shipped at a much later date.

> As soon as you interface with other teams, or even hardware that is still in development, you better make sure that everyone is aligned on the critical details before plowing ahead. Otherwise it can get very expensive (in terms of time, money, and motivation) to prototype yourself into a corner.

Even then, writing a prototype is often a quicker and more effective way to flush out disagreement than endless discussion.

But "endless" discussions or disagreements weren't implied at all. For a sufficiently large and complex project, where every participant (individual or entire teams) is only able to fully grasp a relatively small piece of it[1], there is sometimes just a lot of details to talk through, even if all participants are in full agreement and perfectly willing throughout that entire process.

To stay in the embedded world for an example, sometimes the actual code is just a few dozen lines with a handful of assembly instructions, or even less. But the danger and potential pain those lines of codes might incur on countless involved subsystems, if not properly thought out, even if seemingly "working" at first, can be immense.

[1] To give a sense of scale of complexity in the embedded world for example, the ARM Architecture Reference Manual alone is well over 10000 pages now. And that isn't any actual implementation, and only the "main CPU" itself!

I’m not sure who to reply to in this thread about whether they mean to imply that debugging and simplifying aren’t technical work too.

Finding the right spot to make a 2 line change instead of the wrong spot to make 8 five line changes is seriously technical work

The problem is essentially the following: in a know-all situation (prototype, reduced domain, startup,..) situation it is easy to ditch the 90%. No sync needed, no docs needed, no tests needed, ...

Once you scale up to large systems (ignore complexity) with hundreds of developers then you do and can not know it all. At that moment the churn starts.

And unfortunately, once you get big, regulators, lawyers, audits and other things become a drama as well.

Reply on news.ycombinator.com