Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We will never have enough software developers (2020)

whoisnnamdi.com

Post reply on HN
Print view View original

271–280 of 553 posts

Re: We will never have enough software developers (2020)

#271

Post by throwaway2037 »

Chio wrote: post #243
dt3ft wrote: post #24

Earlier quoted context omitted.

We can’t even push to a git repo unless it has a linked work item/story/task/bug. So, in order to say, upgrade packages or refactor difficult to read code, the work item needs to be approved by a non-tech PO. Guess how much gets done outside of planned/micromanaged? Answer: next to nothing.

I don't believe this is how it is actually implemented in _most_ companies. Where I work every PR must have a linked story / bug / etc but anyone has the rights to create a story so it acts more as a way to track what changes actually goes into a release for x-teams to review and see if they need to document it, etc. In regard to refactors, people tend to just squash them into another change they are making. This mak…

You wrote: >

I would say for non-tech companies with a strict set of IT guidelines, this is mostly true. Please ignore non-tech companies with weak or zero IT culture. It will be the 'Wild West' at those places! Nothing will be maintainable beyond a certain size because there will be so much key person dependency.

For pure tech or tech heavy (banking, insurance, oil & gas, etc.), there is frequently more flexiblity, including "dummy Jiras" just to track a non-QA'able code change like upgrade C++ / DotNet / Java / Python library, or refactor some code. In my experience, 'Jira-per-commit' rule isn't awful, as long as tech debt does not require non-tech approval, and the ticket is just a tracking device. (A few different vendors offer very nice total integration between issue ticket, bug ticket, pull request, code review, etc.) Just a one liner in the Jira should be enough. In my experience, the best teams try hard to "do what works for us", instead of be a slave to the Jira process. Yes, I realise this is highly dependent upon team and corporate culture!

Finally, I would be curious to hear from people who work in embedded programming -- like automotive, aeronautical, other transport, and consumer electronics. I have no experience in those areas, but there is a huge number of embedded programmers in the world! Do you also have a very strict 'Jira-per-commit' rule?

Re: We will never have enough software developers (2020)

#272

Post by sirsinsalot »

finnh wrote: post #266
sirsinsalot wrote: post #246

Earlier quoted context omitted.

I get why bureaucracy is a total pain, getting work approved by stakeholders constantly ... But the actual ticketing/PR system? Change requires control. The actual issue is not _using_ that control tool to get the right things done. If basic technical debt issues are not an easy sell in your org, that's the real problem and one that should be handled by senior/dev manager. A big red flag for me is any org that doesn'…

Requiring a "non-tech PO" to upgrade a package is just broken, though. PMs are good at some things, but giving them power over every minute of an engineer's day is a recipe for badness.

Agreed. I'm not sure I'd let anyone who wasn't from a hands-on SWE background decide the priority of technical work.

Of course, in some cases, it is right to say "Here's the problem, and what could go wrong if we don't fix it. You need to accept the risk".

It's a sad fact of life that technical problems need to be sold to non-technical people as they're often the ones shouldering the risk.

Part of my day-to-day is selling tech debt pay-off work to clients who have to pay for it. They rightly ask "why should we pay for this?".

I think in 99% of cases (like your package upgrade example) the systemic failure is elsewhere and the approval is often meaningless and inefficient.

Re: We will never have enough software developers (2020)

#273

Post by lucumo »

rapind wrote: post #95
capableweb wrote: post #79

Earlier quoted context omitted.

Yeah indeed. Coming from someone who had to work with physical labor before I started programming, software developers don't know how good they have it. "The pay isn't great", "treated far too shabbily", "dealing with bugs and bad decisions", "inadequate processes" and so on, sucks when development is the only thing you've dealt with, but you have no idea how it is to actually have a blue collar job if you're actuall…

Any white collar job looks better than McDonalds. It’s a ridiculous comparison. I could say McDonalds workers don’t know how easy they have it. They should try picking fruit as a seasonal immigrant, because it will make them love working at McDonalds.

> Any white collar job looks better than McDonalds. It’s a ridiculous comparison.

I've had a colleague who was paid worse as a software engineer than his previous job as a McDonald's burger flipper. I also have software engineer friends who were paid minimum wage as software engineers.

I learned from that that having a high-value skill means nothing if you're not willing to take action to extract that value.

Re: We will never have enough software developers (2020)

#274

Post by michaelt »

sirsinsalot wrote: post #246
dt3ft wrote: post #24

Earlier quoted context omitted.

We can’t even push to a git repo unless it has a linked work item/story/task/bug. So, in order to say, upgrade packages or refactor difficult to read code, the work item needs to be approved by a non-tech PO. Guess how much gets done outside of planned/micromanaged? Answer: next to nothing.

I get why bureaucracy is a total pain, getting work approved by stakeholders constantly ... But the actual ticketing/PR system? Change requires control. The actual issue is not _using_ that control tool to get the right things done. If basic technical debt issues are not an easy sell in your org, that's the real problem and one that should be handled by senior/dev manager. A big red flag for me is any org that doesn'…

> Change requires control.

But code, unit tests, git commit messages and merge requests are already providing 4x documentation of code changes. Adding Jira tickets and production deployment documentation gets you to 6x documentation.

In my experience, if your company's problems weren't solved with 4x documentation, they won't be solved by going to 6x documentation.

Re: We will never have enough software developers (2020)

#275

Post by ttymck »

> perennial labor shortages unless the pace of change slows sufficiently

This frames it as a one-way cause and effect ("unless"). I wonder if the "dropout of fast learners" that _causes_ the labor shortage will in turn _cause_ the pace of change to slow!

I think it follows that an industry full of slow learners might have a lower propensity for introducing change (i.e. developing new frameworks) and adopting change (choosing a new framework over one I'm already comfortable with).

Re: We will never have enough software developers (2020)

#276

Post by vitaflo »

jayd16 wrote: post #234
JackMorgan wrote: post #5

A fascinating premise, and matches what I saw as an engineering director. The best just get bored and move on. I think many teams are unaware how much extra value is possible by retaining existing employees vs hiring new ones. Each year I'd try to make sure I was "making them an offer they couldn't refuse" with new interesting challenges, new tech, plenty of personal research time, as much pay increase as I could pos…

>The best just get bored and move on. Is that the premise? Seems to be saying that constantly changing skills exhausts developers to the point that it becomes more lucrative to work in another profession. Although, I suppose learning new things just to tread water can be boring too.

This is how I read it too. That a fast learners skill is degraded in a field that is constantly reset (software dev) vs one where you can stack knowledge. And thus the fast learners will eventually leave the software field and transition to one that doesn’t reset constantly so they can stand out more.

Doesn’t have to do with boredom so much as maximizing potential.

Re: We will never have enough software developers (2020)

#277

Post by bryanrasmussen »

trashtester wrote: post #77
willjp wrote: post #15

Re: skill churn I got the impression that there is much less of this in lower level languages. It seems like there is a fairly stable foundation of C, Cpp that everything else is built on top of. I wonder if embedded programmers have this problem.

> I got the impression that there is much less of this in lower level languages. Not only the lower level languages, but fundamental skills in general, I think. Undertanding the computer from the hardware level, OS level as well network protocols, filesystems etc tend to continue to provide benefits even if one fashionable technology is replaced by another. Similarly, fully undertanding algorithms, data structures, d…

>If so, you may find that you are able to take up senior roles even involving technology you have not used before, as long as the tech introduces few new fundamental ideas.

But will you be hired for those roles? Not that many companies will do that I think.

Re: We will never have enough software developers (2020)

#278

Post by heretogetout »

cabraca wrote: post #7
JackMorgan wrote: post #5

A fascinating premise, and matches what I saw as an engineering director. The best just get bored and move on. I think many teams are unaware how much extra value is possible by retaining existing employees vs hiring new ones. Each year I'd try to make sure I was "making them an offer they couldn't refuse" with new interesting challenges, new tech, plenty of personal research time, as much pay increase as I could pos…

its not just the best ones. If you remove people from the grind for 1-2 days a week, give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time. The main problem is how micromanage-y the current development processes are. Everything has to be a ticket/user story and has to be planned and approved by some people that never even wrote a single line of c…

We have a lot of bugs everyone complains to me about and I have sufficient downtime to fix them* but I have to go through drawn out planning, UI, UX processes before I can even start. I just don't bother any more.

And yeah, it's definitely not just the best ones. I am mediocre and am so bored and so done with dev.

* the downtime is there because I am waiting for planning, UX, and UI for a different high priority task.

Re: We will never have enough software developers (2020)

#279

Post by jmcgough »

cs137 wrote: post #10

There isn't a shortage of software developers. The pay isn't great--the kids getting $300K packages out of Stanford are an exception; it's a marketing expense. In fact, if you control for the level of intelligence it takes to be any good, SWEs make less (and get far less autonomy--do you think lawyers work on Jira tickets?) than any other professional, and they hit a salary/challenge plateau quick... after which, the…

Lawyer pay honestly isn't that great. I know lawyers who went to top schools and routinely work 60-80 hour weeks to make as much as SWE do.

The lawyers who didn't go to top schools became public defenders etc and make about 70k a year and are saddled with a quarter million dollars in law school debt.

Re: We will never have enough software developers (2020)

#280

Post by paxys »

goldenshale wrote: post #240

I think this article hits on some truths and gets a handful of things wrong. First, they are correct that we are in a dynamic profession that requires constant learning and expanding. No doubt the people who choose to stay in software are likely to be people who are curious, life-long learners where this is a benefit of the profession rather than a drawback. That said, one thing I noticed from teaching computer scien…

It's a mix of both. You need to have solid fundamentals and need to keep learning new ways to apply those fundamentals in the real world. There is absolutely effort involved in learning a new language, library, framework, platform no matter how good you otherwise are.
Post reply on HN