Comment by zackmorris | Hacker News Reader

Comment by zackmorris | Hacker News Reader

I wish that the article mentioned the fourth level of seniority: graybeard. Bluntly, that's any developer over 40. But in terms of mindset, it's more like having multiple years of experience in a discipline spanning 2 or more eras so that you begin to see solutions outside of the immediate problem space in front of you.

So for example, a graybeard in the 1990s knew desktop development as well as the web. In the 2000s it was probably web and mobile dev, then NoSQL and reactive programming in the teens. Today it might be digging up old sysadmin knowledge for containerization, or applying functional programming to big data and machine learning problems. Maybe the definition gets fuzzier over time :-P

The problem with all of this is the danger of being put out to pasture. I hit an existential crisis last year where I stopped seeing things in code and started seeing everything like this big spreadsheet that I had to keep consistent. Satisfying multiple constraints in very large search spaces started giving me decision fatigue and I reached a point where my productivity fell below the junior developer level. Like, I'd be given a ticket to fix a bug in a view controller and discover that the problem was actually due to an incorrect relationship in the database schema from 10 years ago. After awhile, nobody wanted to hear about refactoring, they just wanted it to work, and we began the long death march of playing whack-a-mole with technical debt. It felt like there was nothing for me to contribute, and I burned out.

Now I don't know if I should continue programming, or try to transition to being a mentor in a management role, or get out of the industry altogether and move to something like renewable energy and build stuff in the real world. I'm still struggling, so any thoughts on this would be much appreciated.

You're right-- nobody wants to hear about refactoring. Management instead hears "time sink and no additional revenue" (which isn't true, since too much technical debt reduces velocity-- but you're the engineering expert, not management. For a moment, let's forgive their naivete). So when you pick up tickets, build more time into your estimates. Adding 30% more time to your estimates isn't crazy, since estimates are often wrong, and people frequently go over them. This really is a communication issue with how you package up your discussion of time allocation to management. Before exiting industry, I would consider giving this strategy a try.

I’ve seen ex-engineers in management positions (one very well known and experienced engineer in particular) forget how important it is to offset technical debt. I think, more than naïveté, product managers just become consumed by feature-making and feel unproductive if there’s not a constant rush to hand new features off to engineering (which are then rushed to release).

> I’ve seen ex-engineers in management positions...forget how important it is to offset technical debt

I see this across industries. It seems easy for former insiders to lose the ability to empathize with those in their former positions.

Another example: teachers who become principals.

my charitable take is that they don't forget, but they have a hard time explaining to customers why the next release has fewer new features. "now with fewer crashes!" isn't really a good marketing pitch.

It's a fantastic pitch to the existing customers who have suffered through those crashes.

When OS X Snow Leopard was announced, this was the intro slide: http://2ig18m1zutag3bjpoclbo8am-wpengine.netdna-ssl.com/wp-c...

I think some part of this is that technical debt is invisible to the people that don't directly deal with it, so it's easy to underestimate how much of it there is.

We, collectively, need to get better at communicating the cost of the technical debt we face in each project. I stress that this is a two-part conversation: the engineers need to get better at explaining the amount of it in terms that matter to the end user, and management needs to learn to understand what the engineers are trying to say.

Let's also not forget that the engineers are the ones who produced the technical debt in the first place. The earlier it can be identified and weighed against other business desires, the better. Speak up about it not only once it sucks but also when it is created in little pieces.

This reminds me of an article posted here a week or so ago (and posted many times before that) about working in a "feature factory":

https://news.ycombinator.com/item?id=22335738

It's worse. There are two cases I've observed.

The first is that some of these managers never really understood technical debt in the first place. They ascended to the position because they were willing to do "what it takes" to get the job done, with a "can do" attitude that often meant bowling over those who tried to keep sanity.

The second is the people who learned the right way, got into management, and then were crushed by the deadlines and expectations and the only thing they could figure out (while keeping their job) was to acquire more technical debt until it wasn't their problem anymore.

I always hear one of the two things when I say refactoring.

1. We will see, if we have time.

2. Why is it not written better the first time?

The first option is mentioned by managers who have been developers before and understand stuff like this, but need to balance the delivery aspect.

The second option is said either by clueless managers and senior developers who think an all-encompassing upfront system architecture/design would have been the solution. I can talk to the senior developers about it but I don't know how to respond to the clueless managers yet.

Edit: s/hear two/hear one of the two

Refactoring is (as Uncle Bob puts it) an implementation detail. That means management doesn't understand its value, so they should not be expected to take ownership over it.

As engineers we need to just do it, and build it into our tasks.

A car mechanic doesn't ask the customer if its ok if he calibrates his widgetometer -- he just does it as part of the job. The customer has no idea what a "widgetometer" is (neither do I), so of course they will push back on paying for it to be fiddled with.

This is the approach I typically advocate. I actually like to think of quality, depending on the project of course, a bit like an LSM tree.. Well, in the sense that I expect new code and features to be a bit more loose and chaotic. Over time though, the chaos should be reduced and "compacted" if you will as code is revisited and patterns emerge(rule of three).

Of course a certain amount of developer continuity and familiarity with the code helps a lot with this approach.

Imo, this is silly and condescending. I've worked with plenty of team leads and PMs who understand the value of refactoring at some level.

In your analogy, I would say the implementation details would be things like which wrench is used, which hand turns the wrench, how many turns it takes to loosen/tighten something, exactly how you hold the bottle of widget fluid to pour it into the right widget fluid opening under the hood, etc.

The concept of which widgets are being fixed seems crucial to the full picture of understanding the state change of the system (car) before and after the work is done. The owner is paying for the state change in the system.

> "After awhile, nobody wanted to hear about refactoring, they just wanted it to work, and we began the long death march of playing whack-a-mole with technical debt..."

This is exactly why I don't work on web stuff anymore, front- or back-end. Working on products means that, for good or for ill, one _has_ to care about keeping technical debt down to a manageable level or the product collapses.

I'm 36 now but didn't start my software career in earnest until 33. Prior to that I had a lot of leadership experience (as well as being a software hobbyist). What kind of beard will I be when I turn 40?

neck...?

scnr

I think it depends on the culture and the relationship between engineering and management a lot. Good places I’ve been at management will create the buffer and time for engineers to refactor (within reason) instead of just patching things. Great places I’ve seen management isn’t even the gate keeper. They help set the objective and engineers decide how to execute. If that’s a quick patch then fine, if it’s spending more time to completely rewrite something then fine too, as long as the relevant impact is communicated.

I’m only 32 but I started with DOS and later desktop programming, moved on to LAMP in the 00’s, then SPA in the 10’s, and now going heavily to serverless+JAM.

Hell I even had a tiny app make it into the official KDE distribution in high school. And I built my own templating language transpiler for a custom PHP framework ...

What does that make me? Whitebeard lol?

Well I think the whole pirate/ninja thing is a great metaphor for hackers, so technically you are a blackbeard. My friend and old business partner is 3 years older than me but still highly productive making games in Unity, so I think of him as a wizard or maybe a whitebeard. I'm just, haggard, so feel like a graybeard even though I can't grow one.

well, 40 is a hard cut off into gr(a|e)ybeard society. So, at the moment you are a "wannabe" ;)

I think anyone who is pushing 2 decades ish or more of writing quite diverse software is likely a gr(e|a)ybeard. I started programming when I was 8, I'm now 48 and literally have a mostly a gr(a|e)y beard :)

I don't know, but do you have a blog? I struggle from this too. Right now my solution is side projects, but I can only do this because I have very low expenses.

Reply on news.ycombinator.com