5 ms·

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 havin

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.

Swizec 7y ago
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?
- zackmorris 7y ago
  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.
- keithnz 7y ago
  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 :)
ThrowawayR2 7y 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..." 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.
JMTQp8lwXL 7y ago
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.
- jaredgorski 7y ago
  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).
  - heymijo 7y ago
    > 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.
  - leetcrew 7y ago
    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.
    - kqr 7y ago
      It's a fantastic pitch to the existing customers who have suffered through those crashes.
    - 7y ago
yibg 7y ago
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.
IggleSniggle 7y ago
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?
- dvdgsng 7y ago
  neck...? scnr
invalidOrTaken 7y ago
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.
justanotherc 7y ago
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.
- Rapzid 7y ago
  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.
- Benjammer 7y ago
  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.

Swizec 7y ago

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?

zackmorris 7y ago
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.
keithnz 7y ago
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 :)

ThrowawayR2 7y 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..." 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.

JMTQp8lwXL 7y ago

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.

jaredgorski 7y ago
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).
- heymijo 7y ago
  > 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.
- leetcrew 7y ago
  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.
  - kqr 7y ago
    It's a fantastic pitch to the existing customers who have suffered through those crashes.
  - 7y ago

yibg 7y ago

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.

IggleSniggle 7y ago

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?

dvdgsng 7y ago
neck...? scnr

invalidOrTaken 7y ago

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.

justanotherc 7y ago

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.

Rapzid 7y ago
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.
Benjammer 7y ago
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.