7 ms·

I was writing production code over 30 years ago (C, OS, database). It is much worse to be a software developer now. It used to be a very high autonomy job - whe

I was writing production code over 30 years ago (C, OS, database). It is much worse to be a software developer now. It used to be a very high autonomy job - where you were trusted to figure out your work process and usually given lots of freedom to dynamically define many of your deliverables (within reason). I remember when I first read about Agile - I looked at the practices and thought "I've done most of those." But when our nightly builds broke it was no big deal, we would just fix them when we got around to it (as opposed to managers now assigning blame and calling in people on weekends to "fix" it). And if things weren't going well then we might have daily brief meetings for a couple of weeks. But now there are managers who insist on daily standups irregardless of their actual business necessity. I could go on and on. There is a reason why I'm not a practicing programmer anymore - even though I love to code.

walshemj 8y ago
Yes calling out people for a broken build in dev is a waste of time, money and also that mangers emotional capital with the team. You do the 24 hour call outs with 15 min response times for key business processes a live monthly billing run for example.
- InclinedPlane 8y ago
  This depends entirely on the org. In many places with lots of engineers a broken build means hundreds of people are blocked n their work, it's bad news, lost productivity, slipped schedules, it's legitimately a high priority (page someone to fix this) issue. But that's not always true, especially at smaller dev shops. However, smaller shops sometimes like to imitate the big corporations, it makes them feel more important, even though it's not necessary. In both cases having broken builds in your production pipeline are an indication of a process or policy problem more than anything else, especially in 2018 when build hardware is cheap and CI platforms are everywhere. (P.S. I've worked in both types of orgs. Ones where the builds had several teams of people working on them, where broken builds could mean huge amounts of lost or blocked work hour by hour and fixing builds was a very high priority task, and where there were huge systems and extensive policies designed to forestall build breaks getting checked into important branches. All of those systems and policies were built out of a history of chaos, where builds were almost always broken (if you have thousands of devs, and none of them take build breaks seriously, then there will almost always be one break checked in every day), schedules were unreliable, etc. So much so that it was burning people out. On the other hand I've also worked in places where a build break can be handled by filing a bug and letting it go through the normal process of triage and fix over a period of many days. Which process is appropriate is entirely dependent on context.)
  - maxxxxx 8y ago
    "schedules were unreliable," They still are unreliable. the only difference I see is that I spend a lot of time on reporting status instead of doing actual work.
  - walshemj 8y ago
    Only if you let a broken build into prod
  - bostik 8y ago
    A surprisingly good workflow improvement will be to run tests on master + your feature branch, and then have a bot push to master. No humans need to be involved in the final steps. This way master can be always green, because build errors will crop up in branches - only once the tests pass and review is complete, the bot can push to master. Because builds are generally done from master, this prevents landing broken code that could break others' development flow. The end result is that all build failures have been addressed in the development branches. Bot will refuse to merge code that fails tests - and the workflow itself will guide towards a desirable process.
    - rurban 8y ago
      Exactly. If the build is broken, it's broken because of the manager who allowed and is responsible for this broken process. If the smokes are not green, if there is no coverage and no code review it cannot affect your master or prod branches. Humans need to be involved in the code review step. Even if everything is green and covered it still can be wrong or unmaintainable.
- damagednoob 8y ago
  Completely agree. If your last commit broke the build revert it and enjoy the rest of your weekend.
maxxxxx 8y ago
I agree. I started 25 years ago. My first projects were pretty much "Here is the problem. You guys figure it out.". And off we went for months without much reporting back to management. Now everything is very "professional" and process driven and you barely get space to breathe and think about something. God forbid to do any experiments. I don't envy young people who get into the business now. A lot of them will probably never get the chance to work on something uninterrupted for a long time. Instead they are being micromanaged daily, have to justify every little thing they do and don't get much opportunity to make mistakes and learn from them. I guess most industries get boring once they mature. Working on cars between 1900 and 1950 was probably much more fun than working on modern cars in a modern car dealership.
- toomuchtodo 8y ago
  Tech is like being a football player or an exotic dancer: you have a shelf life. Some people can make it a life long career, I haven't seen that to be the case though. Get in, make as much as you can, get out into a sane industry. Plumbers, carpenters, electricians, electrical linemen, welders, lots of trades make similar to what you'd make in tech, the jobs can't be outsourced, and you deal with a lot less day to day bullshit (and you usually have a union protecting your wages and benefits, as well as no such thing as unpaid overtime).
  - maxxxxx 8y ago
    A lot of trades people also have a shelf life. It's hard work and you may not be able to work as carpenter or welder after 50. I agree about unions. The older I get the more they make sense to me. The tech industry is living off exploiting young people's enthusiasm with the promise of a big payoff that materializes only for a few.
    - toomuchtodo 8y ago
      > I agree about unions. The older I get the more they make sense to me. The tech industry is living off exploiting young people's enthusiasm with the promise of a big payoff that materializes only for a few. Can't agree more with this. When I rail against the tech industry, it isn't as a Luddite, but as someone rallying against exploitation and subjugation.
mixmastamyk 8y ago
s/irregardless/regardless/ No need to double-negate this word.
- lazyant 8y ago
  They are both accepted words. https://www.merriam-webster.com/dictionary/irregardless https://www.merriam-webster.com/dictionary/irregardless
  - mixmastamyk 8y ago
    Doesn’t change the fact that it is already negated (with -less) and longer. No need for it to exist, like flammable and inflammable meaning the same thing, haha.
  - tuesdayrain 8y ago
    The phrase "I could care less" is similarly accepted, but that will never stop me from judging people who say it.
    - combatentropy 8y ago
      The linguist Steven Pinker says that it is sarcastic.
  - coldtea 8y ago
    By the dictionary, not by us.
- MrTonyD 8y ago
  You know, I actually changed it from regardless to irregardless. I like the fact that irregardless seems to have a connotation of wanton disregard. So my use of the "double negative" was intentional and supported my point.
  - mixmastamyk 8y ago
    I don't care to be honest, not a big grammar person. In English however, "two negatives are understood to resolve to a positive." It undermines rather than supports the point, folks focus on that instead of your message.
teddyh 8y ago
Robert ‘Uncle Bob’ Martin has a theory about what happened, starting around 1970, to change this to the present situation: https://www.youtube.com/watch?v=ecIWPzGEbFc#t=47m30s https://www.youtube.com/watch?v=ecIWPzGEbFc#t=47m30s
- Terretta 8y ago
  TL;DW: Number of programmers doubling every 5 years means at least half of all programmers are completely inexperienced, overwhelming the number of teachers, so kids stuck learning by remaking mistakes. OTOH, certainly worth the watch even if just from this point to the end, easy listen at 1.5x speed.
  - teddyh 8y ago
    What you say is true, but that wasn’t the initial cause of it, according to Martin. As I understand it, Martin says that since there were no CS degrees until about 1970, the first “generation” of programmers were internal company transfers/promotions of existing employees into the programming department; therefore those people were disciplined and mature (both figuratively and literally). But as soon as there were new fresh CS degree graduates, companies preferred to hire those since they were cheaper. This produced two effects: 1. The CS graduates were, for some reason or other, mostly young men, so the gender balance tanked. 2. The new CS graduates, fresh out of school, were neither disciplined nor mature, and so required a lot of micro-managing. Both these effects were made more or less permanent by the steady growth which you summarized, and the second of these two effects is the change which user MrTonyD lamented above.
codr4 8y ago
Same here, I couldn't bring myself to contribute to the current drama for all the money in the world. This crap has to crash an burn first, then I'll be more than happy to help create something better. While I'm waiting; I'm writing the code I always wanted to write just the way I feel like [0]. https://github.com/codr4life/snabl https://github.com/codr4life/snabl

walshemj 8y ago

Yes calling out people for a broken build in dev is a waste of time, money and also that mangers emotional capital with the team. You do the 24 hour call outs with 15 min response times for key business processes a live monthly billing run for example.

InclinedPlane 8y ago
This depends entirely on the org. In many places with lots of engineers a broken build means hundreds of people are blocked n their work, it's bad news, lost productivity, slipped schedules, it's legitimately a high priority (page someone to fix this) issue. But that's not always true, especially at smaller dev shops. However, smaller shops sometimes like to imitate the big corporations, it makes them feel more important, even though it's not necessary. In both cases having broken builds in your production pipeline are an indication of a process or policy problem more than anything else, especially in 2018 when build hardware is cheap and CI platforms are everywhere. (P.S. I've worked in both types of orgs. Ones where the builds had several teams of people working on them, where broken builds could mean huge amounts of lost or blocked work hour by hour and fixing builds was a very high priority task, and where there were huge systems and extensive policies designed to forestall build breaks getting checked into important branches. All of those systems and policies were built out of a history of chaos, where builds were almost always broken (if you have thousands of devs, and none of them take build breaks seriously, then there will almost always be one break checked in every day), schedules were unreliable, etc. So much so that it was burning people out. On the other hand I've also worked in places where a build break can be handled by filing a bug and letting it go through the normal process of triage and fix over a period of many days. Which process is appropriate is entirely dependent on context.)
- maxxxxx 8y ago
  "schedules were unreliable," They still are unreliable. the only difference I see is that I spend a lot of time on reporting status instead of doing actual work.
- walshemj 8y ago
  Only if you let a broken build into prod
- bostik 8y ago
  A surprisingly good workflow improvement will be to run tests on master + your feature branch, and then have a bot push to master. No humans need to be involved in the final steps. This way master can be always green, because build errors will crop up in branches - only once the tests pass and review is complete, the bot can push to master. Because builds are generally done from master, this prevents landing broken code that could break others' development flow. The end result is that all build failures have been addressed in the development branches. Bot will refuse to merge code that fails tests - and the workflow itself will guide towards a desirable process.
  - rurban 8y ago
    Exactly. If the build is broken, it's broken because of the manager who allowed and is responsible for this broken process. If the smokes are not green, if there is no coverage and no code review it cannot affect your master or prod branches. Humans need to be involved in the code review step. Even if everything is green and covered it still can be wrong or unmaintainable.
damagednoob 8y ago
Completely agree. If your last commit broke the build revert it and enjoy the rest of your weekend.

maxxxxx 8y ago

I agree. I started 25 years ago. My first projects were pretty much "Here is the problem. You guys figure it out.". And off we went for months without much reporting back to management. Now everything is very "professional" and process driven and you barely get space to breathe and think about something. God forbid to do any experiments. I don't envy young people who get into the business now. A lot of them will probably never get the chance to work on something uninterrupted for a long time. Instead they are being micromanaged daily, have to justify every little thing they do and don't get much opportunity to make mistakes and learn from them. I guess most industries get boring once they mature. Working on cars between 1900 and 1950 was probably much more fun than working on modern cars in a modern car dealership.

toomuchtodo 8y ago
Tech is like being a football player or an exotic dancer: you have a shelf life. Some people can make it a life long career, I haven't seen that to be the case though. Get in, make as much as you can, get out into a sane industry. Plumbers, carpenters, electricians, electrical linemen, welders, lots of trades make similar to what you'd make in tech, the jobs can't be outsourced, and you deal with a lot less day to day bullshit (and you usually have a union protecting your wages and benefits, as well as no such thing as unpaid overtime).
- maxxxxx 8y ago
  A lot of trades people also have a shelf life. It's hard work and you may not be able to work as carpenter or welder after 50. I agree about unions. The older I get the more they make sense to me. The tech industry is living off exploiting young people's enthusiasm with the promise of a big payoff that materializes only for a few.
  - toomuchtodo 8y ago
    > I agree about unions. The older I get the more they make sense to me. The tech industry is living off exploiting young people's enthusiasm with the promise of a big payoff that materializes only for a few. Can't agree more with this. When I rail against the tech industry, it isn't as a Luddite, but as someone rallying against exploitation and subjugation.

mixmastamyk 8y ago

s/irregardless/regardless/ No need to double-negate this word.

lazyant 8y ago
They are both accepted words. https://www.merriam-webster.com/dictionary/irregardless https://www.merriam-webster.com/dictionary/irregardless
- mixmastamyk 8y ago
  Doesn’t change the fact that it is already negated (with -less) and longer. No need for it to exist, like flammable and inflammable meaning the same thing, haha.
- tuesdayrain 8y ago
  The phrase "I could care less" is similarly accepted, but that will never stop me from judging people who say it.
  - combatentropy 8y ago
    The linguist Steven Pinker says that it is sarcastic.
- coldtea 8y ago
  By the dictionary, not by us.
MrTonyD 8y ago
You know, I actually changed it from regardless to irregardless. I like the fact that irregardless seems to have a connotation of wanton disregard. So my use of the "double negative" was intentional and supported my point.
- mixmastamyk 8y ago
  I don't care to be honest, not a big grammar person. In English however, "two negatives are understood to resolve to a positive." It undermines rather than supports the point, folks focus on that instead of your message.

teddyh 8y ago

Robert ‘Uncle Bob’ Martin has a theory about what happened, starting around 1970, to change this to the present situation: https://www.youtube.com/watch?v=ecIWPzGEbFc#t=47m30s https://www.youtube.com/watch?v=ecIWPzGEbFc#t=47m30s

Terretta 8y ago
TL;DW: Number of programmers doubling every 5 years means at least half of all programmers are completely inexperienced, overwhelming the number of teachers, so kids stuck learning by remaking mistakes. OTOH, certainly worth the watch even if just from this point to the end, easy listen at 1.5x speed.
- teddyh 8y ago
  What you say is true, but that wasn’t the initial cause of it, according to Martin. As I understand it, Martin says that since there were no CS degrees until about 1970, the first “generation” of programmers were internal company transfers/promotions of existing employees into the programming department; therefore those people were disciplined and mature (both figuratively and literally). But as soon as there were new fresh CS degree graduates, companies preferred to hire those since they were cheaper. This produced two effects: 1. The CS graduates were, for some reason or other, mostly young men, so the gender balance tanked. 2. The new CS graduates, fresh out of school, were neither disciplined nor mature, and so required a lot of micro-managing. Both these effects were made more or less permanent by the steady growth which you summarized, and the second of these two effects is the change which user MrTonyD lamented above.

codr4 8y ago

Same here, I couldn't bring myself to contribute to the current drama for all the money in the world. This crap has to crash an burn first, then I'll be more than happy to help create something better. While I'm waiting; I'm writing the code I always wanted to write just the way I feel like [0]. https://github.com/codr4life/snabl https://github.com/codr4life/snabl