> Software engineering reliably undergoes a major technology shift at least every 10 years.
Maybe that was true in the 90s, but I don't think it is true anymore.
Programmers: Before you turn 40, get a plan B (2009)
441–446 of 446 posts
Re: Programmers: Before you turn 40, get a plan B (2009)
#442Earlier quoted context omitted.
At 35, I finally had real, full control over multiple languages, could pick up CLR and understand and implement any algorithm in it, finally understood exactly why concurrency was so damn hard and how to mitigate that, and would pass practically every interview with flying colors. I could finally drive my tools with some facility and started to realize gdb was my friend. You may be an expert in multiple languages but…
But some things translate much better than others: Django and Rails aren't that different (I'd also put Laravel in there). So I think the real problem is moving from a senior Django role to a senior Rails role and vice versa, but I see no reason why a 10 years Django developer can't get a mid-level Rails job (other than blatant age discrimination that is).
Isn’t that the point? That if you have 10 years worth of experience as Django developer, you aren’t as attractive to someone looking for a Rails developer as someone with 5 years of Rails development.
Re: Programmers: Before you turn 40, get a plan B (2009)
#443Earlier quoted context omitted.
> as many of the younger crowd can't or won't learn it. Or don't need to learn it. Web dev jobs are more plentiful than C++ jobs and need different skills.
Maybe. Writing good software is a skill that isn't particularly language dependent. Most web devs don't. A true polyglot is always going to be more valuable than someone who can only write websites.
You're assuming that "write websites" is the only thing a web developer does. Running web services at scale requires polyglots who understand multiple tech stacks as well as distributed computing, databases, networking, and operating systems.
Re: Programmers: Before you turn 40, get a plan B (2009)
#444Earlier quoted context omitted.
Re: consultants, depends on the engagement. If you engage with clients where you are effectively the only way for them to get anything software done (ie, not in addition to an on-site engineering team), you can be seen as an invaluable resource that just gets things done for the business.
Doesn't that fall apart over time? The consultant quickly becomes the monopoly provider, and the large amount of previously investment means that the customer can't afford to switch to another provider (since anything from the previous company will either go away (if there's a bad contract) or just ends up being very difficult to maintain. And the consultancy has incentives to create this rather than fight this. I'm…
Say a business needs some web dashboards, you write them in a way that should be clean and maintainable, and has documentation for the next person to come in and help if needed later. They like what you did so ask for more of your help. They could decide to change at any time but like working with you and how you get things done, so keep going with the contract.
I don't see how that could be seen as bad. You are helping the business, they are happy, paying, and you've even made it so if they wanted to switch it could be done in the easiest possible way. Did I miss something you'd be concerned about?
Re: Programmers: Before you turn 40, get a plan B (2009)
#445Earlier quoted context omitted.
Doesn't that fall apart over time? The consultant quickly becomes the monopoly provider, and the large amount of previously investment means that the customer can't afford to switch to another provider (since anything from the previous company will either go away (if there's a bad contract) or just ends up being very difficult to maintain. And the consultancy has incentives to create this rather than fight this. I'm…
Say a business needs some web dashboards, you write them in a way that should be clean and maintainable, and has documentation for the next person to come in and help if needed later. They like what you did so ask for more of your help. They could decide to change at any time but like working with you and how you get things done, so keep going with the contract. I don't see how that could be seen as bad. You are help…
I see nothing concerning in what you've described, except that they are totally at your mercy for whether you are delivering what you describe.
EVERYONE will say that the code is clean, maintainable, and has documentation that is meaningful for the next programmer to come along. Not everyone will be lying about that, and if I made it sound that way, my apologies.
But if the next programmer comes along and says the code is a mess and poorly documented, the company is STILL not sure what's true. Is this next programmer the one with an issue? Was the original not stating the truth? Are both fine and this is a philosophical difference of approach? You can ask around...but you have no real way to judge the comments you get, and they have all the incentives to create misleading info.
There's a power imbalance. I'm not saying consultancy is evil, and I'm not saying the power imbalance is avoidable, but in the context of the article - I'm not a big fan of encouraging the _furtherance_ of such a power imbalance, because once you get in, there's very little means of getting out.
Re: Programmers: Before you turn 40, get a plan B (2009)
#446Earlier quoted context omitted.
Say a business needs some web dashboards, you write them in a way that should be clean and maintainable, and has documentation for the next person to come in and help if needed later. They like what you did so ask for more of your help. They could decide to change at any time but like working with you and how you get things done, so keep going with the contract. I don't see how that could be seen as bad. You are help…
I see nothing concerning in what you've described, except that they are totally at your mercy for whether you are delivering what you describe. EVERYONE will say that the code is clean, maintainable, and has documentation that is meaningful for the next programmer to come along. Not everyone will be lying about that, and if I made it sound that way, my apologies. But if the next programmer comes along and says the co…
You make a good point, and I don't disagree there are possible downsides. To be fair, some of the details you described could be issues with in-house employees as well, imho (folks/teams claiming clean/maintainable code when it's not, wanting to seem necessary, having the power to claim what the team is doing is right and good for business without business knowing any better, etc).