Live data from Hacker News

We will never have enough software developers (2020)

whoisnnamdi.com

381–390 of 553 posts

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

#381
post #226

Earlier quoted context omitted.

Average construction worker, bartender & hotel worker don't have a Bsc/Msc.

Average SWE doesn't need one either. Most of the people I once worked with in the service industry had degrees though. Sure, not compsci, but something. Also most construction workers I've know made way more than that average, often close to 6 figures if not above it. Of course I'm in a big city, may skew things.

Maybe that's a geographical thing; I live in Europe, and there are barely any SWE without a master or equivalent here.

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

#382

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…

> No doubt the people who choose to stay in software are likely to be people who are curious, life-long learners The article showed the opposite effect though. Curious, life-long learners stop working in software development because they have to constantly learn new skills and believe they can get more bang for their buck when they can invest in skills that don’t lose their value over time.

Yes, this is how I feel. I have no problem learning a new skill. I get discouraged when I learn a new skill and just when I start to get really comfortable and productive with it, it's suddenly "legacy" and some new thing is popular.

The only skills that have really stood the test of time for me are C, PHP, unix shell stuff, and SQL.

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

#383
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 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…

I think that many companies don’t know or have forgotten that programming is a creative process more than a manufacturing process. You’re not pulling chicken breasts off an assembly line and wrapping them in plastic.

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

#384
post #331

Earlier quoted context omitted.

Worse, industry is routinely bashing on CS degrees because they don't turn people into framework X-ready candidates. It's getting a little tiring just how little credit is given to the idea of "maybe these tools can be learned in a reasonable amount of time by people with a degree showing they can pick things up rather quickly".

Yes but I interview for a role where we dont have set languages: we're a small optimisation team working across system when they reach capacity bottleneck and we do JS, C#, Java, C++, PL/SQL fixes completely transparently, we've slowly learned that languages really dont matter all that much for performance tuning as much as programmers mishandling which are identical in all of them (hash map loops, abusive recursion,…

Anything can be learned in a reasonable amount of time, but I already have a job. Good luck in finding your candidate though, sounds like a great environment to work in :)

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

#385

There is no shortage of swe. What I see and what I have experienced first hand is that companies, especially the more hyped/small ones, pretend to be FAANG and gets very picky when interviewing. They often employ FAANG style interview. Now, if I really have to spend that much time prepping to interview at your unprofitable company (that most likely will go under) don’t you think that I would try my best to work at fa…

Companies have only tested my code skills and handed me personality tests when applying for full time jobs. As a freelancer, I get one or two interviews where I talk to the architects, tech leads and managers, and that's it - either I'm in or out after that. They end up treating me as an employee anyway, so don't really know why this distinction is made in the first place, but I suspect HR.

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

#386

Earlier quoted context omitted.

I'm not sure that's a like-for-like comparison and if those things overlap like that, it sounds wrong: - Ticket: Description of the requirement - Code: How it was done - Review: Peer-learning, change evolution - Unit test: Testing of implementation as understood by SWE - QA: Did the change match the requirement, did the SWE understand it? Is the outcome the right one? Each "item" should serve a distinct purpose, have…

- Ticket: AB-123 Increase the API maximum page size from 500 to 1000 - Code change: MAXIMUM_PAGE_SIZE -500 +1000 - Unit test: assert len(request[0:2000]) == 1000 - Commit message: Increase the API maximum page size from 500 to 1000 - Merge request: Increase the API maximum page size from 500 to 1000. For AB-123 - Daily scrum update: I've increased the API maximum page size from 500 to 1000, if someone could have a lo…

I know what you mean, but to be a bit of the devil's advocate here (only half kidding):

As a reviewer of such a pull request, I'd go over all the places in the code where this page size constant is used.

I'd also like to see a rough assessment of the impact of this change. Does it affect a lot of code? Some code? What percentage of users are to be affected by this change?

Also, who asked for it? It's ok if no user asked for it and it's your own initiative. But if users did ask for it (or rather complained something like "the app rejects our API requests" or "the app is effin slow, please fix"), then it'd be nice to connect to their tickets / mails / chat logs. This could serve as a proof to management if someone decides to question this change.

Deployment: If this change is in an API called by many functions (so, big impact), but it can bring with it a big benefit to many users, I'd like to see a rollout plan - as simple as putting it into a beta version, or (if we have them) using feature flags to enable it, and a plan (can be an automated script) that tracks crashes during this rollout. If the change doesn't have a big impact then that's not necessary.

Ideally I'd like to see coverage results that proves that all those functions which use this constant and all code paths leading to them have coverage. It's perfectly ok if they don't, perfect is the enemy of the good, but at least the major ones. I would also go over carefully at least over some of the code which uses this constant directly and indirectly to ensure no funny business like too many threads allocating this bigger buffer, no funny out of bounds issues due to code assuming size is of a certain length (if it's C/C++/C#) etc.

So really, what is the user-visible impact of this change? If it has no user-visible impact, then why was it made? The ticket as it was specified here doesn't answer this question and therefore reflects a somewhat broken organization/team, where engineers are disconnected from their users and/or lack the eloquence or willingness or time to explain their changes. I bet the person who wrote this doesn't even bother writing comments about non-obvious changes (such as this one!), making their code harder to maintain.

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

#387
post #42
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…

Shit that bugged them for a long time might have a lot less value to the business than a tedious task that nobody wants.

Shit that bugged them for a long time can multiply overall productivity going forward, and add far more value than slowly banging out the next user facing feature in a low productivity environment.

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

#388
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…

This is... To be charitable: uninformed. As a civil engineer: I assure you my studies were QUITE rigorous. The job is very demanding, and I assure you the complexity can be very high, the consequences of mistakes are severe and occur over a massive variety of time scales. I had to work for four years apprenticing under licensed engineers after school and pass no fewer than four examinations, and get 4 licensed engine…

80k for 8 years of experience with a PE is a bit low. You should be cracking six figures by now if you’re structural and coming close if you’re actual (roadway) civil. Are you in materials testing? If so, obviously you should try to switch over to an inspection gig to get some of that sweet overtime. I was clearing something like 110k salary at similar experience back when I practiced and quite a bit more with my equity/COLA/bonus, but I was in a high risk niche field. Not sure where you’re at but any market of reasonable size should be able to support you getting a raise, especially if you’re actually as good as you think.

I agree with everything you say. Software engineers (most should not even be called engineers, they’re coders or developers and on the same level as a lab technician to me) are prima donnas whose mathematical and scientific backgrounds are (on average) at least one level of education behind any actual licensed engineer/professional making half as much. And their degree of liability is infinitely lower, as you note. I’ll probably get sued or be involved in a lawsuit for my work another half dozen times before 2032 even though I haven’t stamped anything in 3 years.

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

#389
I think the profession is too new for the research data to really make sense. The sample size of devs with 20y of experience can't be comparable to that of the devs with 2y experiencie. I think the statistics from the paper stop making sense with the higher ages.

I'm 26 years old. I have no idea what my future looks like. Neither do other people my age.

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

#390
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.

Guess how much would get done if you learned to explain why that work is important to a non-technical colleague? Lots. People don't always understand code, but they do understand problems, and why those problems are important to keep on top of. If your PO is sensible then a couple of paragraphs explaining why refactoring is important with a closing line that says spending a week catching up on refactoring now will sa…

Explaining why maintenance is necessary time and time again (tech evolves fast) is soul-crushing and quite frankly rather demeaning. I need x amount of hours for maintenance work every sprint, or the codebase will slowly become outdated and undesirable to work with. Again, tech evolves and changes rapidly, open source packages die quite often. Maintainers abandon their packages (my PO likely has no idea that we rely on free open source software to ship features), there are security issues with using abandoned packages… To sum up: when I see issues, I want to fix them. If I have to go through a corp process and ask for time to fix the issues… I sort of tend to lose the apetite/mood. This right here is the core issue.
Post reply on HN