The Plot Thickens ..
Apple will pay for female employees who elect to freeze their eggs to delay childbearing.
This is purely so that they can find a suitable donor and incubator for Project iRegenerate: the master plan to recreate Steve Jobs.
Miserable software developers produce miserable software, to the further detriment of organizational productivity and personal health. Researchers from the University of Stuttgart, University of Helsinki, Free University of Bozen-Bolzano, and the Norwegian University of Science and Technology have completed a study [PDF] of …
"They don't like
poor quality code, bad codebases, or
refactoring. They resent code complexity, code
reviews, and difficult problems. They resent
technical infrastructure that constrains them
and poor documentation. They can't stand
vague requirements, unrealistic requirements,
or the chore of code maintenance."
sounds like they're in the wrong job.
"I don't like the term knowledge worker, its almost as bad as sex worker. I'm all for calling a prostitute a prostitute, and a programmer a programmer."
How about 'Bit Wrangler', sounds more dynamic and go getting !!! :)
Pity that the Job Title does not change the job.
Job Title does not matter, while the 'crap you shovel' does. !!!
BTW:
Note how all the areas highlighted are 'Problem' being fixed after the fact.
A bit :) more thought earlier in the process to anticipate the future problems would eliminate many of these or at least lessen them IMHO.
All these " employee perks, largely to keep difficult-to-replace technical talent from leaving for greener pastures. Google has climbing walls. Facebook has on-site barbers" are not relevant, if the hard problems remain unsolved. Things such as long build times, poor workflow, poor dependency management, undisciplined colleagues etc. And the thing is, these do not have to be outright "solved" because developers understand these are hard problems. Usually it is enough for developers to see that these problems are being addressed or at least understood by management.
And if they're not but it's just par for the course? My company offers above market rates, work from home, and flexible(ish) hours. And free fruit. Great, I should be happy.
Unfortunately as well as the work itself being a bit boring, they expect us to maintain huge ancient codebases with vi and don't run static analysis tools and have no interest in changing things. Well, heads are nodded in meetings but that is all that happens.
If I find another job I could quite easily earn half and be out after a year or two, such is the labour market where I am, so it seems I'm going stay and write sad code.
"they expect us to maintain huge ancient codebases"
That's probably the code that's paying everyone's wages, including those of devs doing all the shiny stuff. The shiny stuff will either become legacy in due course or be forgotten about while the old stuff keeps running and running.
They should let you use any code editor you like, it's not hurting them in any way. Otherwise maintaining huge ancient code bases is pretty much par for the course unless you work for a startup. I personally don't mind working with old code, even if it is terrible, as long as I'm allowed to clean it up and refactor as I go.
Management that isn't interested in improving methods makes working somewhere pretty hard. If you're feeling the way you seem to be I'd recommend looking for another job, otherwise you'll just be miserable all the time.
If you want to motivate your coders, give them interresting things to do. Allow them to express themselves and to make mistakes. Allow them to try to reinvent things. Hire competent people. If everybody thinks they can learn from their peers, it creates a very pleasurable athmosphere of constant learning and discovery.
Decarbonated sparkling water and such is just the way clueless HR drones try to solve the problem. That way you get the same boring list of employee benefits at every company.
Very early on in The First Circle, one of the imprisoned scientists or engineers cuts across another's long explanation and quotes a study that said that contented cows give more milk. I certainly don't mean to compare the situation of techies even in the crappiest jobs with that of prisoners, but rather to say that the principle has been around for a while.
As for the in-house barbers, meals, etc., they sound to me like inexpensive ways to keep programmers around the campus longer. If providing a $20 lunch will cut half an hour off a highly paid coder's break, the gain for the company is clear. And if providing a dinner means that a 6 p.m. dinner is not the end of the workday, but a break before a couple more hours, the company gains still more.
I'm not sure I believe this study. I reckon programmers made miserable by having to maintain awful legacy codebases are actually more likely to produce simple, no-nonsense, maintainable code. Happy programmers seem more likely to construct elaborate crystal palaces, full of dependencies on the latest flavour-of-the-month tools and frameworks, that will be entirely unmaintainable in 2 years' time.
Actually, maybe the cause and effect are the other way round. Playing with all the new toys, weaving tapestries of golden thread with blithe disregard for the poor saps coming afterward, makes programmers happy. And grinding out boringly competent code with thorough documentation makes them sad.
"Developers, as they report about themselves, have a lot to complain about. They don't like poor quality code, bad codebases, or refactoring. They resent code complexity, code reviews, and difficult problems. They resent technical infrastructure that constrains them and poor documentation. They can't stand vague requirements, unrealistic requirements, or the chore of code maintenance."
Try working in Ops as a DBA or sysadmin and for the 93rd time that week that the database/server is slow, wasting another 15 mins fetching the metrics ( 'cos proper software has instrumentation so we know what it's bloody well doing and don't have to guess! ) to prove once again it's a poor code release that's choking the DB/server and thus by dint annoying the users. Then getting dragged out of bed at 2am 'cos some numpty developer put a delete statement in the batch job release by mistake and the QA team were having a "Friday afternoon" moment and lost the key lookup data, which it's now your problem to restore from the backups.
Yeah, yeah we get it devs are the only poor darlings who are put upon! ( Heavy dose of sarcasm and I need the pub! )
I hate Fridays, Friday afternoons especially. IDK why, In fact 15:30 (current UTC) always used to be when the massive Friday evening blues really kicked in. Ohhh yes, I remember: it's because all the normal people are delightedly going off to enjoy their "lives", partners, kids, gadgets, home cinemas, sport, cinema and all the other crap they pollyfilla the voids in their lives with. Me, I prefer filling it with gin \o/
... you keep everyone stressed and you get poor performance. Quarterly workforce management, for instance, distracts you from your job. Depending on your psychology and circumstances, you either get miserable or you put more effort into looking for a new job.
Many in management think that an atmosphere of constant competition is actually more productive than one of collaboration. In my experience that is very nearly always because they are not nearly as good at anything as they think they are.
The root cause of this dissatisfaction is often unrealistic deadlines. If The Boss is not particularly aware of the nuances of analysis and coding there may be undue pressure to produce results. What a lot of bosses are unaware of is that it might take x days to meet a deadline, but this might be taking major liberties with design, so that when a further deadline is set which, to The Boss, is simply an incremental step, might involve a major back-track. In database work, for example, it may be even confirmed in an email from on-high that "you can leave postal addresses as one field, we'll never need anything more detailed." Then... later... "this report you've done is all very good, but I'd like to see it in zipcode/postcode order" which involves a complete rehash of the address fields.
Having an "interface" between management and those doing the design and coding that understands both budgetary concerns and the technical aspects of coding is essential. Someone who is prepared to dig their heels in when good design and good coding principles are at stake. Get that in place and I suspect motivation and morale will soar.
In database work, for example, it may be even confirmed in an email from on-high that "you can leave postal addresses as one field, we'll never need anything more detailed."
The law of inverse sensitivity:
It's not important == It's critical
I must have it this way == Nobody will care except the one knob-end who'd moved onto something else, never to return, before he even finished speaking.
It won't change == It'll be the most volatile aspect of the whole system
One gap is generally liability on the Sales droid/Turd Polisher side, they are generally liable only to the point of getting the business in, so they promise said customer Diamond encrusted Moon on a Golden stick. Involving unrealistic or unachievable technical goals, combined with unachievable and unrealistic deadlines.
Until there is liability on the delivery goals from the individuals/groups within the business that are responsible for the original agreement with the customer (without negative reflection on those groups due to unrealistic customer expectations), nothing will change.
Another gap is a general micro-management culture in certain businesses.
Work-Life balance.
Excessive Unpaid Overtime expectations. (This is generally due to the above unrealistic deadlines, resulting in a vicious circle of permanent fire fighting, which results in a highly stressed and unmotivated workforce).
Shifting responsibility down, while retaining authority above.
"People Jacking" resulting in the "Many Chiefs not enough Indians" behaviour.
Unrealistic Project Managers (i.e. the 9 Women can make a baby in 1 month types)
This "good lazy programmer" is something of a myth in my experience. The real-world lazy programmer is doing CTRL-C, CTRL-V on huge swathes of code and creating tons of duplication, because they're too lazy to refactor it out into some common class or library. Or they're creating bugs by copying stuff off Stack Overflow without bothering to figure out how it works.