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

241–250 of 553 posts

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

#241

Post by voxic11 »

dfsegoat wrote: post #215
voxic11 wrote: post #196

Earlier quoted context omitted.

In my company it depends on the repo but worst case is you get arrested for making unapproved changes to regulated sports betting systems.

Ouch. Out of curiosity, are those local or federal regulations?

Mostly state level here in the US. The feds just don't allow any type of gambling across state lines but otherwise leave it up to the states to regulate. Its actually a huge pain in the ass to deal with since there has been very little standardization of state regulations so far.

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

#242

Post by kache_ »

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…

If you're not getting paid enough, have you tried leaving your job and finding another one?

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

#243

Post by Chio »

dt3ft wrote: post #24
cabraca wrote: post #7

Earlier quoted context omitted.

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 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 makes the git log a bit harder to follow at times, but people did this back when we just used to push to trunk too so I don't think the story is the deciding factor.

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

#245

Post by lucumo »

groby_b wrote: post #211
mettamage wrote: post #171

Earlier quoted context omitted.

We need data for this. More importantly, we need data for how tough it is to get certain jobs. That means stuff like: * Time spent on finding a job * Time spent on studying in order to attain a job * Actual amount of hours worked (hard to get accurate data on it) * Actual amount of effort per hour (hard to operationalize) It's a very tough discussion to have, but I have a gut feeling that you're simplifying too much…

Or, you know, you could just listen to people. Qualitative evidence is just fine. We might want to stop exclusively fetishizing numbers, and instead of complaining how hard it is to find data, do something to fix the problems right in front of our face.

> Or, you know, you could just listen to people.

Well, that's all dandy. But when someone actually shares something it's "cry me a river". Their contribution is summarily dismissed because it's not the Right Evidence from the Right People.

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

#246

Post by sirsinsalot »

dt3ft wrote: post #24
cabraca wrote: post #7

Earlier quoted context omitted.

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 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't recognise and service technical debt and empower engineers to make a win.

I also wouldn't say tech debt pay-off should be without its justification in some cases. If an engineer can't measure the positive impact of doing something, it can make it a hard sell. Why should an engineer spend 2 weeks doing something if we can't describe the payoff?

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

#247

Post by mattgreenrocks »

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…

> If you remove people from the grind for 1-2 days a week

The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out.

I realized the other day that a big part of my drive to move towards self-employment is really just a way to carve out time to take adequate care of myself. I have significant doubts that it is possible to continue to advance in tech to staff+ levels, be a good spouse, parent, and friend, and not run myself into the ground with physical/mental issues. And that is sad on multiple levels.

So I respond by easing up on advancing my career, because it gives back to me the least.

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

#248

Post by whimsicalism »

woeirua wrote: post #238
whimsicalism wrote: post #210

Earlier quoted context omitted.

Personally I do because I enjoy working with very smart people. The backlash against leetcode is the same as backlash against other types of tests: most people are going to fail and most people don't like failing, so they blame the test.

I guess Sergey and Larry weren't "smart" then because they never went through a leetcode interview.

If you think what I just said implies what you just said, then you are the type of person I would not want to work with.

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

#249

Post by commandlinefan »

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…

> has to be planned and approved

It gets worse, too - as long as I've worked as a software developer there's been some sort of time tracking system in place, and it has to be planned up-front, and has to work out to at least 40 hours (after they "negotiate" your estimates down). Which leaves no time for the unplanned stuff that inevitably comes up. This always goes in a cycle like this:

1. Management demands that every bit of work be associated with a ticket

2. devs just open tickets for the unplanned stuff so that it shows up in the ticket tracking system

3. management complains about devs opening "their own" tickets and prohibits self-opened tickets

4. devs do the unplanned (always "super high priority!") stuff without any ticket tracking and fall behind on their "planned" tickets (that nobody really cares about any more, but are still on their board)

1. management demands that every bit of work be associated with a ticket...

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

#250

Post by Frost1x »

popotamonga wrote: post #229
xur17 wrote: post #207

Earlier quoted context omitted.

I've worked at companies that tried to have explicit 20% policies, and it worked okay for some period of time, but then became difficult to prioritize. That said, I've typically been pretty successful at casually using 10 - 20% of my time to work on random low hanging fruit (dev ergonomics, performance, etc). For some reason using a quiet Friday afternoon, or time between tickets seemed to work better than an explici…

At my old place they just overestimated my tasks complexity by 200-300%. I wasnt going to be the one saying no... So i had plenty of time to fix whatever.

I've always been a fan of the under promise and over deliver paradigm in tech. Overestimating gives you nice fat error margins should something unplanned come up, you're not slaving evenings and weekends away trying to meet a rough estimate that someone turned into a deadline for scheduling.

Once you finish meeting minimum requirements, should you have that margin padding, you can then refine what's been created. Fix issues or shortcuts you may have taken, improve or optimize some portion that'll give significant improvement in experience, add some additional functionality you think would be nice to have where permitted (while the context of everything is fresh in your mind).

Ultimately what's delivered will more often than not meet minimum requirements so whomever requested the work will be satisfied. They may even be incredibly pleased and consider you a wizard for some of the improvements (they also may not want the improvements so be sure to keep those modular you can very easily slice them off if they're undesired).

This keeps everyone happy really. When you start trying to optimize on the estimates so they reach actual time or a little under actual time to pressure developers to do OT, that's when you get into toxic environments. If you give a little error margin developers will likely reinvest it in your application where it sparks joy in them meaning you're about to get the highest quality work, the stuff the engineer wants to do.

Post reply on HN