12 ms·

How Going Back to Coding After 10 Years Almost Crushed Me

135 points by mellosouls 6y ago

altacc 6y ago
Apart from the headline and a parenthetical reference, there isn't really any insight here about why returning to coding almost crushed him, which would have been more interesting than yet another list of things common in modern development. I have a similar switches between management and occasional development and there are a lot of "interesting" and frustrating challenges in returning to coding after a break of several years. Hearing other people's experiences helps dealing with the frustrations. There is a lot of tooling, frameworks, build processes, etc... which weren't widespread a decade ago which make starting a side project or jumping into code only occasionally an obstacle course for those who do not do it regularly. I'm ever grateful to those who write good how to guides for these things that I can refer to when I miss a crucial step in my setup.
- diydsp 6y ago
  I have my own rule for headlines. You can almost universally swap out the word 'How' for 'That'. e.g. "That Going Back to Coding After 10 years Almost Crushed Me."
- rbreaves 6y ago
  I feel this - there's been a definite shift in using some surprisingly large frameworks it seems like and it does take time to ramp up with them.
- bartvk 6y ago
  Yup, I also couldn't find what exactly almost crushed them. That would've been the most interesting here.
- rob74 6y ago
  Yeah... smells a bit clickbaity to me! If you decide to use such a title, you should at least expand on it in the article a little bit more than the "(although it almost crushed me)" at the very end...
xeox 6y ago
Non walled version : https://archive.is/UNYn2 https://archive.is/UNYn2
nonameiguess 6y ago
Surely, this guy realizes this is highly dependent on where you're working. Release managers, QA teams, and dev->test->prod issues are absolutely not gone. Arguably, dev->test->prod issues are even worse than they used to be if you're utilizing vendor-locked services that are difficult or impossible to effectively mock or simulate, and even worse than that when you're part of a multi-vendor enterprise solution where your service needs to interact with other services you don't develop and that don't actually exist yet because they're all being developed at the same time, in which case you're forced to mock an incomplete spec that may or may not end up actually getting implemented. These new realities the author talks about are the only case if you're making sole source standalone services utilizing only externals that use stable, open APIs or standard protocols.
- jcun4128 6y ago
  What sucks is when you have all these things that have to run for __your__ piece of code to work and something goes down, it's another team that has to deal with it and they're not available. For example whatever handles oAuth in a local domain/test environment. When that goes down and the entire app/test harness doesn't work... at least there are other domains to use in our case but sometimes those are down too.
  - hinkley 6y ago
    If I never have to explain again to someone that it’s THEIR JOB to investigate 500 errors from their code before someone has to come ask them about it, it’ll be too soon. Set some alerts please.
- dx034 6y ago
  Sadly, some people interpret agile and scrum as getting rid of QA teams. Of course you can release faster if no one has to manually check the feature but it just turns the user into the QA team. And no developer can properly test their own code. I absolutely welcome automated testing wherever possible but for any software with a user interface (including websites) it can never fully replace manual testing.
mikewarot 6y ago
I've been out of it for 30 years, and I have to dive back in. The hardware is amazingly fast compared to 1990, and as I frequently note, GIT makes a huge difference in being able to refactor, compared to a folder full of ZIP files. The frustrating thing for me is that GUI development has apparently gone backwards a decade or so, with the rise of web frameworks and all the extra layers and connections between the user and the actual data. It used to be that you could grab some components in VB6 or Delphi, and have your database prototype up and running in an hour, and make a stream of modifications as required, with the main delay being pkZIP and copying files prior to making any big changes, just in case. Compile cycles even then were in the 0.5-5 second range, like now. I've wimped out and use a GUI version of GIT and GitHub, but it is amazing to start a project, and once it's running, push commits to the internet with a single click. The main limits I see right now are, My age - I'm 57 My skillset doesn't include the Rust, Clojure, etc... The programming languages are less impedance matched to the human mind than they were in the past. Pascal made you type a lot of things, but that also made it far less ambiguous, and much, much easier to read and write. I expect to wait, but not to get crushed. For me, programming is easy, except when it isn't, then its a persistence hunt for the cause of the open issue.
- throwaway3699 6y ago
  Most of the trendy languages like Rust and Clojure are irrelevant. As ever it's C++ and Java that still dominate.
  - typon 6y ago
    Python and Javascript are the new languages that dominate compared to 10 years ago.
    - lumost 6y ago
      As a trend, I've noticed that there are more companies with python/ruby/go/js based stacks than java/c++ stacks. However there are more jobs for Java/C++ than all the rest. Large firms like Google/Amazon/Apple etc. tend to have an unquenchable need for skilled java/C++ devs. Going beyond the top firms large startups like Square/Uber/SalesForce similarly use java stacks.
arduinomancer 6y ago
Honestly the part on daily stand ups sounds like a negative to me. Sick of repeating the same status update every day for no benefit.
- diydsp 6y ago
  After working for 20 years with weekly status, switching to daily status is a big change. It removes developer autonomy and responsibility. Instead of toughing it out and trying different ways to solve a problem, we report our status and management leads us in a different direction each morning. Instead of gaining breadth, we get emasculated. Minor problems get elevated to obsessions, inverting priorities. Over the longer time frame, all the intelligence of the leader is "harvested" and ant-like developers haven't been practicing problem-solving skill so progress ossifies, but people still feel busy because they're trying new things every day. And the new things are only from the repertoire of the leader who isn't developing either. But hey we have chip makers speeding up chips every year, so this will continue. This honestly used to be much more fun in the old days. It was less productive, of course, but also less reverent. It didn't feel like a morning mass or pledge of allegiance, more like the Superfriends.
  - sverhagen 6y ago
    This sounds like a team that would be dysfunctional at doing weekly updates as much as it is now at doing daily stand-ups, except that you get bothered by it five times more often not. Don't blame Agile/daily stand-ups...
    - jiofih 6y ago
      People are a product of their environment as much as the other way around.
  - deanCommie 6y ago
    Man, you must have worked at some really toxic workplaces. I could write a paragraph reputing point by point every single one of your sentences in a healthy organization. All I can really say is you should consider switching jobs. You'll have to take my word for it today but it's way better out there, and you can join a company and a team that will make you feel like NONE of those things (yet still have daily standups)
diydsp 6y ago
>developers now own the test writing and CI infrastructure runs and reports the tests. It has really made software more reliable I switched from medical, with fierce QA, to more general SW dev over the last 3 years. Developers waste time writing braindead unit tests and don't stress their software like QA teams. Major bugs run undetected for weeks and cause chaos. Managers grin believing they're net-ahead.
- bigtimegames 6y ago
  Hmm i think the pace of changes has made software break more, but unit tests and integration tests are an improvement. But I agree writing unit tests takes a hella lotta time, not sure if a sr eng should be doing that 1/2 the time
- 01100011 6y ago
  I'm at a FANG with some of the smartest people I have ever encountered in my life, yet no one seems to agree with me that devs should not write their own tests. There is an unwavering belief that knowing the corner cases and weak points of your own code makes you somehow better at writing the tests. We also seem to be obsessed with testing that is half-way between unit level testing and system level testing. We test APIs and features more or less in isolation. Tests should be written by antagonistic developers who are not at all familiar with the code. They should stress the capabilities promised in the interface documentation. Hiring more people who are dedicated to testing costs a lot of money though. I don't see things changing anytime soon.
  - robbyt 6y ago
    The problem is, when devs don't write their own tests, the code they write tends to be untestable.
    - onion2k 6y ago
      I suspect you think the developer writes the code and then the QA engineer writes tests for that code. That's the wrong way round. The tests are written first, and they all fail, then the dev has to write code to make them pass. By definition it's literally impossible to write untestable code that way because then the tests won't pass. It's the principle of TDD but separated in to different roles. It works well and produces good results but you need exceptionally good planning upfront to actually do it.
max1984_2 6y ago
I was out of work during lock-down (I was a consultant) and being out of work for 8 months almost crushed me when I came back to work because I had to remind myself how to do some relatively simple things (e.g. how do I write a mock?). Being out of the industry for 10 years is basically starting from scratch (almost).
ffhhj 6y ago
Going back to coding after 1 year gave me super-programming-powers! :) I had this idea for a killer app that required a lot of deep thinking on the design to make it either a huge success or sunk it on release. I knew whatever I decided on those aspects would also be hard to implement. Every day I would just contemplate the list of pending items in my amazing project for hours, I entered in a spiral of indecision and procastrination that burned me out. Lost all interest in programming. Backed up all my code of years and cleaned my hard disk. Changed work, changed habits and hobbies. No more programming for me. After a year I still haven't recovered my interest in programming, it must be my age, but I still believe my idea is something worth to be completed. Two weeks ago I restored my backup and was able to solve all the critical decisions, implement, test and fix bugs. That would have taken months with all the additional procastrination.
- lelanthran 6y ago
  > Every day I would just contemplate the list of pending items in my amazing project for hours, I entered in a spiral of indecision and procastrination that burned me out. This almost happened to me. I switched to using Emacs org mode to track my personal projects. It lets me do the contemplating in a written form, and I gradually refine high-level targets into sub-tasks until one of them is small enough to implement (at which point I implement it). It also means that if I am blocked (can't think of a good solution) on a project, I just switch o the next one and edit that org file instead. It's worked out really well for me. My projects are still mostly unfinished, but at least now I have time-tracked against what has been done and have clear goals written down so I know where to pick up again. This means that I have actual visual feedback of progress!
deleted 6y ago
[deleted]
ToJans 6y ago
Over the last 2 decades I have switched from development to business owner/management/marketing/sales and back 3 times. Right now, I am doing a rewrite of my online 3d engine for consumer products, after being active for 3 years as an enterprise consultant for mid and large sized organizations, mostly initiating first roadmaps and identifying how to onboard new clients, reorganizing my client's product and solution portfolios, figuring out/maturing pre-sales tracks etc... The reason I switch from development to other tracks and back, is that after a few years I feel like I am stuck in an echo chamber, where I tend to overestimate the value of the thing I am doing, and underestimate the importance of what others do. The biggest disadvantage is that I could have probably retired from a financial POV about a decade ago if I had stayed on the same track, while this might now take another decade, but on the other hand, for me the chase matters more than the catch. The biggest advantage is that - due to my broad experience - my kind of profile is extremely unique, and I can find a well-paid freelance gig in about a week without to much effort if I need some cash to bridge one of my many mini-sabbaticals. This might not be for everyone, but if you like to spend time out of your comfort zone, I would strongly advise anyone who tries to understand the bigger picture to switch every n years; it is super valuable to understand the drivers from both sides and makes the job so much more interesting. Edit: typo
- ChrisMarshallNY 6y ago
  Thanks for that. I’ve found mixing disciplines has been very helpful; especially these days, when I’m the only coder in a startup team. But specialization is still fairly important. I am specialized in Swift (with a minor in PHP). This has been beyond invaluable, in the work I do. To be fair, I am involved in multiple platforms and tech within the Apple ecosystem (like writing stuff to work on all Apple hardware platforms), but that is still a fairly constrained environment. I have found that it’s quite possible to write acceptable software, quickly; especially if we are willing to loop in a great deal of “mystery meat” code, but it’s another matter, entirely, to create awesome code. I once had someone boast to me that they only hire people that can switch languages and environments in a matter of a couple of weeks. Wide and shallow worked 20 years ago. Not so sure it is as effective, these days, as the river is a lot deeper, and runs faster. The stakes for screwups, nowadays, are also pretty terrifying.
imposter 6y ago
Me be like how going back to the code that i wrote 2 months back almost crushed me
ballerburg9006 6y ago
Stupid april fools.
ganafagol 6y ago
Two things don't add up for me in this article. 1. He moved to management 10 years ago. But most things he describes were already a thing at that time. Git existed, unit tests were a thing, we already had a CI workflow at my company at that time. Sounds like he is looking 30-40 years back, not 10. Or he worked at a place that kept innovation outside their doorstep and didn't look at what others did either. 2. Moved to management and got that detached from dev life? All sw managers in my company are up to date with dev practices. How else could they make reasonable management decisions? Everybody up to the CTO is regularly committing code. Not as much as they'd like to, but they are familiar with workflows and have contributed key pieces of our codebase. Meritocracy at its best. Not sure what kind of manager he was, but I doubt I'd have liked to work under him.

135 points by mellosouls 6y ago

Apart from the headline and a parenthetical reference, there isn't really any insight here about why returning to coding almost crushed him, which would have been more interesting than yet another list of things common in modern development. I have a similar switches between management and occasional development and there are a lot of "interesting" and frustrating challenges in returning to coding after a break of several years. Hearing other people's experiences helps dealing with the frustrations. There is a lot of tooling, frameworks, build processes, etc... which weren't widespread a decade ago which make starting a side project or jumping into code only occasionally an obstacle course for those who do not do it regularly. I'm ever grateful to those who write good how to guides for these things that I can refer to when I miss a crucial step in my setup.

diydsp 6y ago
I have my own rule for headlines. You can almost universally swap out the word 'How' for 'That'. e.g. "That Going Back to Coding After 10 years Almost Crushed Me."
rbreaves 6y ago
I feel this - there's been a definite shift in using some surprisingly large frameworks it seems like and it does take time to ramp up with them.
bartvk 6y ago
Yup, I also couldn't find what exactly almost crushed them. That would've been the most interesting here.
rob74 6y ago
Yeah... smells a bit clickbaity to me! If you decide to use such a title, you should at least expand on it in the article a little bit more than the "(although it almost crushed me)" at the very end...

xeox 6y ago

Non walled version : https://archive.is/UNYn2 https://archive.is/UNYn2

nonameiguess 6y ago

Surely, this guy realizes this is highly dependent on where you're working. Release managers, QA teams, and dev->test->prod issues are absolutely not gone. Arguably, dev->test->prod issues are even worse than they used to be if you're utilizing vendor-locked services that are difficult or impossible to effectively mock or simulate, and even worse than that when you're part of a multi-vendor enterprise solution where your service needs to interact with other services you don't develop and that don't actually exist yet because they're all being developed at the same time, in which case you're forced to mock an incomplete spec that may or may not end up actually getting implemented. These new realities the author talks about are the only case if you're making sole source standalone services utilizing only externals that use stable, open APIs or standard protocols.

jcun4128 6y ago
What sucks is when you have all these things that have to run for __your__ piece of code to work and something goes down, it's another team that has to deal with it and they're not available. For example whatever handles oAuth in a local domain/test environment. When that goes down and the entire app/test harness doesn't work... at least there are other domains to use in our case but sometimes those are down too.
- hinkley 6y ago
  If I never have to explain again to someone that it’s THEIR JOB to investigate 500 errors from their code before someone has to come ask them about it, it’ll be too soon. Set some alerts please.
dx034 6y ago
Sadly, some people interpret agile and scrum as getting rid of QA teams. Of course you can release faster if no one has to manually check the feature but it just turns the user into the QA team. And no developer can properly test their own code. I absolutely welcome automated testing wherever possible but for any software with a user interface (including websites) it can never fully replace manual testing.

mikewarot 6y ago

I've been out of it for 30 years, and I have to dive back in. The hardware is amazingly fast compared to 1990, and as I frequently note, GIT makes a huge difference in being able to refactor, compared to a folder full of ZIP files. The frustrating thing for me is that GUI development has apparently gone backwards a decade or so, with the rise of web frameworks and all the extra layers and connections between the user and the actual data. It used to be that you could grab some components in VB6 or Delphi, and have your database prototype up and running in an hour, and make a stream of modifications as required, with the main delay being pkZIP and copying files prior to making any big changes, just in case. Compile cycles even then were in the 0.5-5 second range, like now. I've wimped out and use a GUI version of GIT and GitHub, but it is amazing to start a project, and once it's running, push commits to the internet with a single click. The main limits I see right now are, My age - I'm 57 My skillset doesn't include the Rust, Clojure, etc... The programming languages are less impedance matched to the human mind than they were in the past. Pascal made you type a lot of things, but that also made it far less ambiguous, and much, much easier to read and write. I expect to wait, but not to get crushed. For me, programming is easy, except when it isn't, then its a persistence hunt for the cause of the open issue.

throwaway3699 6y ago
Most of the trendy languages like Rust and Clojure are irrelevant. As ever it's C++ and Java that still dominate.
- typon 6y ago
  Python and Javascript are the new languages that dominate compared to 10 years ago.
  - lumost 6y ago
    As a trend, I've noticed that there are more companies with python/ruby/go/js based stacks than java/c++ stacks. However there are more jobs for Java/C++ than all the rest. Large firms like Google/Amazon/Apple etc. tend to have an unquenchable need for skilled java/C++ devs. Going beyond the top firms large startups like Square/Uber/SalesForce similarly use java stacks.

arduinomancer 6y ago

Honestly the part on daily stand ups sounds like a negative to me. Sick of repeating the same status update every day for no benefit.

diydsp 6y ago
After working for 20 years with weekly status, switching to daily status is a big change. It removes developer autonomy and responsibility. Instead of toughing it out and trying different ways to solve a problem, we report our status and management leads us in a different direction each morning. Instead of gaining breadth, we get emasculated. Minor problems get elevated to obsessions, inverting priorities. Over the longer time frame, all the intelligence of the leader is "harvested" and ant-like developers haven't been practicing problem-solving skill so progress ossifies, but people still feel busy because they're trying new things every day. And the new things are only from the repertoire of the leader who isn't developing either. But hey we have chip makers speeding up chips every year, so this will continue. This honestly used to be much more fun in the old days. It was less productive, of course, but also less reverent. It didn't feel like a morning mass or pledge of allegiance, more like the Superfriends.
- sverhagen 6y ago
  This sounds like a team that would be dysfunctional at doing weekly updates as much as it is now at doing daily stand-ups, except that you get bothered by it five times more often not. Don't blame Agile/daily stand-ups...
  - jiofih 6y ago
    People are a product of their environment as much as the other way around.
- deanCommie 6y ago
  Man, you must have worked at some really toxic workplaces. I could write a paragraph reputing point by point every single one of your sentences in a healthy organization. All I can really say is you should consider switching jobs. You'll have to take my word for it today but it's way better out there, and you can join a company and a team that will make you feel like NONE of those things (yet still have daily standups)

diydsp 6y ago

>developers now own the test writing and CI infrastructure runs and reports the tests. It has really made software more reliable I switched from medical, with fierce QA, to more general SW dev over the last 3 years. Developers waste time writing braindead unit tests and don't stress their software like QA teams. Major bugs run undetected for weeks and cause chaos. Managers grin believing they're net-ahead.

bigtimegames 6y ago
Hmm i think the pace of changes has made software break more, but unit tests and integration tests are an improvement. But I agree writing unit tests takes a hella lotta time, not sure if a sr eng should be doing that 1/2 the time
01100011 6y ago
I'm at a FANG with some of the smartest people I have ever encountered in my life, yet no one seems to agree with me that devs should not write their own tests. There is an unwavering belief that knowing the corner cases and weak points of your own code makes you somehow better at writing the tests. We also seem to be obsessed with testing that is half-way between unit level testing and system level testing. We test APIs and features more or less in isolation. Tests should be written by antagonistic developers who are not at all familiar with the code. They should stress the capabilities promised in the interface documentation. Hiring more people who are dedicated to testing costs a lot of money though. I don't see things changing anytime soon.
- robbyt 6y ago
  The problem is, when devs don't write their own tests, the code they write tends to be untestable.
  - onion2k 6y ago
    I suspect you think the developer writes the code and then the QA engineer writes tests for that code. That's the wrong way round. The tests are written first, and they all fail, then the dev has to write code to make them pass. By definition it's literally impossible to write untestable code that way because then the tests won't pass. It's the principle of TDD but separated in to different roles. It works well and produces good results but you need exceptionally good planning upfront to actually do it.

max1984_2 6y ago

I was out of work during lock-down (I was a consultant) and being out of work for 8 months almost crushed me when I came back to work because I had to remind myself how to do some relatively simple things (e.g. how do I write a mock?). Being out of the industry for 10 years is basically starting from scratch (almost).

ffhhj 6y ago

Going back to coding after 1 year gave me super-programming-powers! :) I had this idea for a killer app that required a lot of deep thinking on the design to make it either a huge success or sunk it on release. I knew whatever I decided on those aspects would also be hard to implement. Every day I would just contemplate the list of pending items in my amazing project for hours, I entered in a spiral of indecision and procastrination that burned me out. Lost all interest in programming. Backed up all my code of years and cleaned my hard disk. Changed work, changed habits and hobbies. No more programming for me. After a year I still haven't recovered my interest in programming, it must be my age, but I still believe my idea is something worth to be completed. Two weeks ago I restored my backup and was able to solve all the critical decisions, implement, test and fix bugs. That would have taken months with all the additional procastrination.

lelanthran 6y ago
> Every day I would just contemplate the list of pending items in my amazing project for hours, I entered in a spiral of indecision and procastrination that burned me out. This almost happened to me. I switched to using Emacs org mode to track my personal projects. It lets me do the contemplating in a written form, and I gradually refine high-level targets into sub-tasks until one of them is small enough to implement (at which point I implement it). It also means that if I am blocked (can't think of a good solution) on a project, I just switch o the next one and edit that org file instead. It's worked out really well for me. My projects are still mostly unfinished, but at least now I have time-tracked against what has been done and have clear goals written down so I know where to pick up again. This means that I have actual visual feedback of progress!

deleted 6y ago

[deleted]

ToJans 6y ago

Over the last 2 decades I have switched from development to business owner/management/marketing/sales and back 3 times. Right now, I am doing a rewrite of my online 3d engine for consumer products, after being active for 3 years as an enterprise consultant for mid and large sized organizations, mostly initiating first roadmaps and identifying how to onboard new clients, reorganizing my client's product and solution portfolios, figuring out/maturing pre-sales tracks etc... The reason I switch from development to other tracks and back, is that after a few years I feel like I am stuck in an echo chamber, where I tend to overestimate the value of the thing I am doing, and underestimate the importance of what others do. The biggest disadvantage is that I could have probably retired from a financial POV about a decade ago if I had stayed on the same track, while this might now take another decade, but on the other hand, for me the chase matters more than the catch. The biggest advantage is that - due to my broad experience - my kind of profile is extremely unique, and I can find a well-paid freelance gig in about a week without to much effort if I need some cash to bridge one of my many mini-sabbaticals. This might not be for everyone, but if you like to spend time out of your comfort zone, I would strongly advise anyone who tries to understand the bigger picture to switch every n years; it is super valuable to understand the drivers from both sides and makes the job so much more interesting. Edit: typo

ChrisMarshallNY 6y ago
Thanks for that. I’ve found mixing disciplines has been very helpful; especially these days, when I’m the only coder in a startup team. But specialization is still fairly important. I am specialized in Swift (with a minor in PHP). This has been beyond invaluable, in the work I do. To be fair, I am involved in multiple platforms and tech within the Apple ecosystem (like writing stuff to work on all Apple hardware platforms), but that is still a fairly constrained environment. I have found that it’s quite possible to write acceptable software, quickly; especially if we are willing to loop in a great deal of “mystery meat” code, but it’s another matter, entirely, to create awesome code. I once had someone boast to me that they only hire people that can switch languages and environments in a matter of a couple of weeks. Wide and shallow worked 20 years ago. Not so sure it is as effective, these days, as the river is a lot deeper, and runs faster. The stakes for screwups, nowadays, are also pretty terrifying.

imposter 6y ago

Me be like how going back to the code that i wrote 2 months back almost crushed me

ballerburg9006 6y ago

Stupid april fools.

ganafagol 6y ago

Two things don't add up for me in this article. 1. He moved to management 10 years ago. But most things he describes were already a thing at that time. Git existed, unit tests were a thing, we already had a CI workflow at my company at that time. Sounds like he is looking 30-40 years back, not 10. Or he worked at a place that kept innovation outside their doorstep and didn't look at what others did either. 2. Moved to management and got that detached from dev life? All sw managers in my company are up to date with dev practices. How else could they make reasonable management decisions? Everybody up to the CTO is regularly committing code. Not as much as they'd like to, but they are familiar with workflows and have contributed key pieces of our codebase. Meritocracy at its best. Not sure what kind of manager he was, but I doubt I'd have liked to work under him.