4 ms·

Why Developers Become Frustrated and Companies Can’t Find Talent

30 points by wyclif 8y ago

preordained 8y ago
I don't know. It's not my experience that whether kicked off by novices or experts or anything in between, that the initial architecture will ever be done so well as to make maintenance and quality some kind of breeze when reality (users) sets in. Only if your problem space is so well known or tidy that it can basically be codified by an expert (which leaves like compilers, and a few other things). I don't disagree that you don't want a bunch of greenhorns laying out the foundations for some big, long-term project. But, I just don't think it is ever realistic to avoid warts, and shortcomings, etc. and things that will "frustrate" developers because they would have built it perfect if only they had been there (accompanied by their hindsight...) but now they have to touch legacy code--icky! That's my .02, but I think we as developers can often be prima donnas this way. It can't all be blue ocean and greenfield (i.e. fun). Dealing with and minimizing the shortcomings of software that has hardened and can't just be completely reimagined is--and will always be--part of the job.
- abc_lisper 8y ago
  Primadonnas is going a little far. There is a lot of code that is really horrible, convoluted, and the meaning is only apparent to people who wrote it. I don’t think this is “just” a problem with programmers, anybody gets frustrated when they don’t understand what’s going on. One can only untie the knots so far, under timelines and repeat it day after day, year after year.
james1071 8y ago
I am only a hobby programmer, but have some observations based on the developers who I have met at various meetups and other gatherings. 1 There is probably a wider range of ability in software developing than in many other fields. 2 Other fields have better methods of filtering the good performers to the good employers. Hence the problem of mismatched employers and developers.
DEADBEEFC0FFEE 8y ago
Why are there two qualities in the diagram? Why is the developers journey a circle? Don't fraustrated experienced, well paid developers quit to do their own new project? If so, do they do them better?
cellularmitosis 8y ago
I agree somewhat with the "developer's journey" diagram, but I noticed the reason given for the "frustration" step is that senior devs get roped into fixing others bad code. This hasn't been my experience. The frustration typically comes from a lack of autonomy. I think scrum is great for guiding junior devs, but as you become more senior, it seems to ensure the company only makes use of your "junior dev" qualities. I don't know why so many companies seem so terrified of letting go of the reins on their senior devs for a few weeks at a time and see what they come up with on their own. I mean, that's where gmail came from...
spirate 8y ago
The startup scene (time and money pressure) may help in that, but IMHO one can only write quality software if the problem is understood enough (or it was already solved before). However, usually, startups keep pivoting now and then trying to make a [new] product guided by customer actual needs (which may be different from what they had started with). I assume good design comes from a holistic view of the problem and experience. if you are solving the problem one bite at a time then this becomes harder (how everything fits together elegantly?). YMMV
ericmcer 8y ago
With how fast stuff frameworks and libraries are becoming old/invalid we are all fooling ourselves if we think code we are writing today won’t be looked at with some disdain 5+ years from now. My current project at work is transitioning a backbone app > react. The app was originally jquery and a team before me moved the whole thing to backbone. There are comments throughout about how good the B.B. stuff is, how solid this new architecture will be. Now I am here three years later replacing it, with no illusions about the longevity of what I am writing.

30 points by wyclif 8y ago

I don't know. It's not my experience that whether kicked off by novices or experts or anything in between, that the initial architecture will ever be done so well as to make maintenance and quality some kind of breeze when reality (users) sets in. Only if your problem space is so well known or tidy that it can basically be codified by an expert (which leaves like compilers, and a few other things). I don't disagree that you don't want a bunch of greenhorns laying out the foundations for some big, long-term project. But, I just don't think it is ever realistic to avoid warts, and shortcomings, etc. and things that will "frustrate" developers because they would have built it perfect if only they had been there (accompanied by their hindsight...) but now they have to touch legacy code--icky! That's my .02, but I think we as developers can often be prima donnas this way. It can't all be blue ocean and greenfield (i.e. fun). Dealing with and minimizing the shortcomings of software that has hardened and can't just be completely reimagined is--and will always be--part of the job.

abc_lisper 8y ago
Primadonnas is going a little far. There is a lot of code that is really horrible, convoluted, and the meaning is only apparent to people who wrote it. I don’t think this is “just” a problem with programmers, anybody gets frustrated when they don’t understand what’s going on. One can only untie the knots so far, under timelines and repeat it day after day, year after year.

james1071 8y ago

I am only a hobby programmer, but have some observations based on the developers who I have met at various meetups and other gatherings. 1 There is probably a wider range of ability in software developing than in many other fields. 2 Other fields have better methods of filtering the good performers to the good employers. Hence the problem of mismatched employers and developers.

DEADBEEFC0FFEE 8y ago

Why are there two qualities in the diagram? Why is the developers journey a circle? Don't fraustrated experienced, well paid developers quit to do their own new project? If so, do they do them better?

cellularmitosis 8y ago

I agree somewhat with the "developer's journey" diagram, but I noticed the reason given for the "frustration" step is that senior devs get roped into fixing others bad code. This hasn't been my experience. The frustration typically comes from a lack of autonomy. I think scrum is great for guiding junior devs, but as you become more senior, it seems to ensure the company only makes use of your "junior dev" qualities. I don't know why so many companies seem so terrified of letting go of the reins on their senior devs for a few weeks at a time and see what they come up with on their own. I mean, that's where gmail came from...

spirate 8y ago

The startup scene (time and money pressure) may help in that, but IMHO one can only write quality software if the problem is understood enough (or it was already solved before). However, usually, startups keep pivoting now and then trying to make a [new] product guided by customer actual needs (which may be different from what they had started with). I assume good design comes from a holistic view of the problem and experience. if you are solving the problem one bite at a time then this becomes harder (how everything fits together elegantly?). YMMV

ericmcer 8y ago

With how fast stuff frameworks and libraries are becoming old/invalid we are all fooling ourselves if we think code we are writing today won’t be looked at with some disdain 5+ years from now. My current project at work is transitioning a backbone app > react. The app was originally jquery and a team before me moved the whole thing to backbone. There are comments throughout about how good the B.B. stuff is, how solid this new architecture will be. Now I am here three years later replacing it, with no illusions about the longevity of what I am writing.