What Happened to Software Development?
hackernoon.com
hackernoon.com
This is someone who prefers solitude. It's not surprising that he doesn't like collaborative work.
He seems to be projecting his own preference onto the software industry though, which is misguided. Lots of great software has been built with all kinds of different workflows.
Nah, he's just a literal rockstar programmer. You've got to give him that.
It was definitely easier in the 90's - less complexity, more freedom to do your own stuff. Project management was less hands-on, and more concerned with reporting up than managing down.
But I like it now. I like that the teamwork matters, and the morning standups are great (good to know what your colleagues are working on, and be able to work out if you need to collaborate with them on stuff you're both touching). I like pair programming on the tricky bits (and being able to admit that some bits are tricky and ask for help without being sneered at).
Programmers used to be treated as weird, eccentric geniuses that you had to handle with care and needed special work environments to thrive in. Now we're just people, and get treated like normal people. I understand how that won't suit some, because they enjoyed being treated differently ("like princes" I guess... but more like princesses because we were effectively locked in a tower).
And as we get older, our tolerance for change decreases. It takes effort to avoid becoming a grumpy old fart, complaining at everything that has changed. But the effort is worth it.
"old farts" rock, my friend. I get that some folks enjoy molding young minds to sick patterns, free of pushback, but ultimately I will contend that it's it's counterproductive to ones true goals. (unless ones true goals are merely to crush human egos and souls...)
I'm an old fart. I have to spend effort resisting the pull to be a grumpy old fart, though. It's not like it used to be, and mostly that's a good thing.
Just the other day a Senior was telling me about one job he went back to where they were bought out. The new people wanted to introduce process into how they work and since most of the devs complained that whole team was let go.
The sad part was he didnt care what he had to do to work. He just wanted to work. So the majority opinion he didnt agree with got him screwed over. If you are going to assume a whole team is rotten please dont. Interview them independently.
1. Get paired with another dev of similar level to work on new stuff. Bouncing ideas makes the surfacing solutions better.
2. Get paired with a dev that has been working on some system for a while. This is a much quicker way to learn the what's and why's of a project.
Everything in modern faddish programming seems to be aimed squarely at stressing out and destroying the effectiveness of introverts.
Introverts are also not being targeted in any way. People who have been at this a while are just very aware that you can get far more accomplished with a team that works well together than an individual developer can. You can be an introvert and still an effective team member. Nobody is fully introverted or fully extroverted.
- Organizations, especially large ones, now trust their process over their people. In the "old" days, when a production problem was identified and the prime developer knew what the problem was, it would be fixed, as directly and immediately as possible if there was high confidence. With less than high confidence, maybe a quick test in a test environment is done. In many places, this is now a multi-day, or even multi-week process now.
- Developers are not all doing it because they love it anymore. It's a high-ish paying job with lots of hiring being done. Many of the people writing code these days are awful programmers that in the long run cause a lot of damage. Many take away more than they add. In the earlier days, people coded because they wanted to.
The second problem is actually a big part of the cause of the first.
Perhaps I'm just bitter, but given the abundance of technologies, frameworks, libraries, services, etc, small teams of good coders can put together amazing pieces of work in a very short time. This almost never happens. It seems like complexity of large software projects has exceeded the ability of the current level of general expertise to maintain. It sure seems like we're close to that point.
I should add that I don't have the same opinions on most modern techniques. Agile can work very well. Code reviews and unit tests are a must. These are all tools that boost the quality and in the end, save time as well.
My take on the issue is that we have lost the distinction, and now everything is enterprise software development. No matter your size and the scope of your project you must adopt THE enterprise way of developing. The reason is that using the same processes and tech that a FAANG/Unicorn has basically become a requirement in term of signaling, both for companies and developers.
Edit: What we miss is that at that size they are (rightfully) solving processes problems. But for startups it's irrelevant (or premature optimization at best). Previously it was simpler: companies with 1000+ developers were not cool.
and ultimately, who PAYS for all these deliberate hurdles and the deliberate curtailing of human productivity to serve a tangential dubious (at best) goal?
It was great back then; we were treated like princes [...]
The situation has become so bad that I cannot find many companies I can work for that has not succumbed to this fad. The only workplace that works for me now are the ones where I can work remotely.
EDIT: I'm apparently a blind idiot in the morning. Misread the parent comment.
Refactoring a bit less, but it is also a very clear term so other people know what you are doing.
This has followed the shift of oftware development from a capital investment to more of an operational one. The job profile of operational work doesn't fit neatly within the solo developer / deep flow paradigm. Sure, that might be necessary for some dev jobs, but most dev jobs are more figuring out what needs to be built than actually building it. And for better or worse (usually worse for those of us on the spectrum), every job seems headed in this direction.
How much of that is incidental complexity, though? What happened to refactoring and paying down technical debt - weren't these supposed to be tenets of Agile?
Software also does more and integrates with more than it ever has. This is driven by customer requirements, which are pretty much non-negotiable.
It's initially easier to sell software with that quick-and-dirty approach, but if you keep doing it you'll find that you're incurring a lot of technical debt. Which you'll need to pay down in some way, if you want your software to be "constantly improving".
If you're right that customer requirements are requiring more essential complexity of our industry, keeping these dynamics in check can only be even more important, rather than less.
Developers think a lot about technical debt as it relates to engineering (and they should!), but I find that "product debt" (features that need to be combined / streamlined / reimagined for UX / product purposes) is actually more meaningful in most contexts. This can make conversations with product folks difficult as engineering and a product owner often have very different ideas about what the phrase "technical debt" means. It can be hard to pay down either when you're talking past each other.
> If you're right that customer requirements are requiring more essential complexity of our industry, keeping these dynamics in check can only be even more important, rather than less.
The world is simply a lot more complex and interconnected than it was 20 years ago when the type of development OP describes was still widespread. I don't think we can put the cat back in the bag. Agile approaches honestly reduce the complexity by not building anything that isn't being asked for and being intentional about which tech debt to pay down.
It can do those things, but it very rarely does, even by well-meaning teams.
It’s time to drop the “should help” and adopt the “...but historically, did it really?”.
Changing that mindset I found to be a nearly impossible task.
One of the oldest cliches in software development is "faster, better or cheaper -- pick two". The prevalence of Agile basically means that "faster and cheaper" is the default answer to this question. If you want "better," the CMMI still exists (and is still heavily used in defense / aerospace).
Agile is very likely to have played a role but I don't feel the correlation between it and the current state of programming is that strong. There are other factors that mixed with it.
What I will always agree with is that Agile / Extreme Programming brought about much needed pressure to stop the waterfall approach in every single area of engineering, programming included. That's the historical role I attribute to it and for that I am very grateful.
Anything beyond that, I am fairly sceptical. Agile didn't really do that much in the grand scheme of things.
Many too young to have ever seen the halcyon days of software development...
Every generation has blinkered old guys talking in that way, who can safely be ignored. There has never been a more exciting time to code, especially away from the corporate treadmill.
I particularly lost patience when he started talking about the Beatles (and I love the Beatles). Mate, if you came of musical age in the early nineties it's spelt Nirvana. Or Wu Tang. Whatever, he sounds like he was always looking back.
Can they? Here we are in 2019 and we're reinventing (usually in worse shape) everything people already had in the 70s, 80s, 90s, even the 60s (Go is closer to Algol than to a 2019 language, our IDEs are worse than LISP machines or Smalltalk environments). We all use UNIX (a 70s technology), OS X/iOS (a variation on a 80s microkernel + BSD), and Windows (a 30+ year old OS design, from a prominent 70s/80s OS designer). We reinvented techniques used 40+ years ago in mainframes as containers. Our UI tech of choice is the DOM...
>Mate, if you came of musical age in the early nineties it's spelt Nirvana.
So? I did, and they still have 1/10th the complexity and breadth and reach of the Beatles. They're not better musically or lyrically or culturally or production wise or music playing wise (so not in any way).
They're just closer to the age familiar to the 90s teens. So you're accusing him of clinging to what he knows from his youth, when you're infact clinging to an inferior standard (Nirvana vs Beatles) just because you know it from your youth.
So even this makes the author's argument for him...
Every generation reinvents stuff, and adds new inventions of its own. People shouldn't just dismiss new creators as inferior out of some chronological quirk, just because those people were born at a later time, or because low-hanging fruit are gone. It's exactly the same condescending and arrogant tone that consigns all young creative people to being "unlucky" to have been born when they are.
Ironically, the Beatles - and the tech wizards of the past never listened to that moaning nonsense either from their own older rose-tinted, time-locked colleagues, they just got on and changed the world.
You wrote: "if you came of musical age in the early nineties it's spelt Nirvana", so one is entirely justified to argue based on that.
>Every generation reinvents stuff, and adds new inventions of its own.
Well, that's the "everything is always the same, just with different flavors" argument.
I don't buy it. In history (of science, art, inventions, etc.) we can see that are long periods of stagnation, bursts of higher creativity, eras of repetition, eras of exponential growth, etc.
Of course it isn't justified to make that assumption, here I'll show you:
if you came of musical age in the 90s it's Nirvana, Wu Tang, whatever
if you came of musical age in the 60s it's the Beatles, Motown, Rolling Stones, whatever
if you came of musical age in the 80s it's NWA, the Smiths, Michael Jackson, whatever.
You can surmise nothing about me except I have some understanding of pop history; you are also reading into my first comment a comparison of worth that is a separate discussion and not remotely connected to my original point.
To repeat: argue the point, not your presumption of the person.
As for the rest of your comment, I'd broadly agree with a suspicion of relativism and your summary; but you are leaping from that to an unhealthy dismissal of an entire generation - which attitude is generally associated with the sort of moribund conservatism that all great talents - of whichever decade or century - always fight against to the death.
The text was just a tedious hard-to-follow rant. Flow isn't that special: It's a state of mind when you're engaged in relatively easy logical work, while unsynchronized with other people's work.
Frankly, modern corporations only appreciate productivity, innovation, creativity and spontaneous combustion, when executed at the dictate of Directors. So whenever you found a sweet spot, know that Change (Winter) is coming.
I like working remote but I also like working in the office a couple days a week to connect with my team members.
It's possible that these ideas taken to the extreme are bad but taken in moderation can be great.
Open offices...are still the most horrible idea ever.
Ayup....
Agile malpractices doesn't mean that writing software with more agility is bad, and I found odd that he derides pair programming but at the same time derides TDD because of the misconception that it means that a second pair of eyes is no longer needed.
And, of course, the pretense that the biggest reason MS was successful after it was no longer inside a garage was due mainly to anything other than scummy corporate and monopolistic practices is... Suspect, to say the least. MS, from all appearances, became awful once it was more than ten people, but that's got nothing to do with agile practices.
About the life story, I never cease to be amazed at the level of personal freedom offered by a career in programming. I have friends who move to far away places, take long sabbaticals, etc. What a great thing.
It completely ignores that masses of people do not work effectively that way.
In the field of learning people have long realised that sitting down people for a 3 hour session learning doesn't work, it actively inhibits learning. Why is it not the same for applying knowledge.
The problem is one-size-fits-all prescribed solutions, telling people how to be productive. Depending on where a person is in a project, their mood, phase of the moon, etc, they may be more productive collaborative or heads down. It varies by person and time. I think there is room to respect how individuals work best.
agree 1,000,000%
the thing is, it takes exactly zero courage or risk to cheer for the status quo.
the other thing is, later we often realize that the system was wrong, and the iconoclast was right.
where does the true arrogance actually lie?