> I decided to pack up and go, and left the USA on 11/15/2010, intending to retire at 56, play my guitars, read my physics library, live my life in very strange language and relax.
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.
I've worked in both environments (I too was coding in the 90's).
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.
.... and there you go proving the authors point about derision and subtle sneers aimed at what is arguably the most effective means of getting focused highly productive developers: treating them like HUMANS, instead of faceless cogs, and allowing for focused programming time without distractions.
"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 said nothing about treating people like humans, or not, and nothing about focus (I completely agree that developers should work in their own offices, and love working from home myself). I said we used to be treated like socially inept geniuses, left to our devices because no-one understood what the hell we were talking about. And now we're treated like everyone else. If that doesn't mean "like a human" then you're working for the wrong organisation, my friend.
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.
> 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.
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.
Because it is awful for people who don't enjoy social interaction, and get quickly worn out by it. Which encompasses a much larger share of programmers than the general public.
Everything in modern faddish programming seems to be aimed squarely at stressing out and destroying the effectiveness of introverts.
Pair programming isn't intended to be an all the time thing. A great example of pair programming is a new person gets hired and you pair program with them on a ticket so they can ask questions along the way. Having recently joined a remote startup I found this to be pretty essential to getting anything done. It's a great way of elevating programming level as well. You see different ways of doing things, different tools they use, etc.
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.
Like everything the author listed it's about execution and applying the right tools to the right job. Some places _only_ do pair programming, some places go so wild with their unit tests that it becomes incredibly unwieldy, and lots of times different approaches get cargo culted from organizations where it made sense (we're a 10,000 member team writing a new OS) to a one where it doesn't (we're 2 people making a CRUD app side-project that got a little traction).
In my (probably worthless) opinion, the two big problems affecting software industry are:
- 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.
Ok boomer! that said I feel the same, having worked solo for 10 years. 99% of the stuff i read about in this forum is about processes, management, code review, packaging, testing, automating deployment. Who is doing the actual building? It used to be that , with software, "processes" are automated leaving you with only the highest-of-the high level entities, the code, which is brief like poetry. Code seems less powerful nowadays, not a tool to create, but hidden under layers and layers of process. I 'm kind of thankful i don't have to work for others ever again, but i m also missing out on SV-level salaries. How much time do people spend writing program rather than checking in and out of various systems?
I think these two kinds of environments always cohabited. In the 90's/00's you had enterprise software development (think old school J2EE) which was all about processes (and boilerplate code), with the smallest feature taking months to implement (and usually resulting in an over-engineered outsourced low quality mess). On the other side you had small shops environments like ID Software and startups with a completely different philosophy.
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?
I do understand the criticism of open plan offices and the resulting interruptions, I do myself prefer a closed office. And I definitely haven't been around as long as this person. That being said, it feels like this person is just upset that they're not "at the top" anymore. Quote:
It was great back then; we were treated like princes [...]
Open space offices is another similar fad that I cannot stand. Who wants to be at the constant risk of being interrupted and be distracted by side-channel chatter!
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.
Open source offices are a result of companies not willing to train. Everyone wants to hire someone with experience in their tools, and also only hire young people, so what are young people going to do? They're going to teach themselves free tools.
EDIT: I'm apparently a blind idiot in the morning. Misread the parent comment.
"Refactoring" and "technical debt" are just faddish meaningless words? Alright,buddy. From one old programmer to an even older one, you really are just being a grumpy old man.
Fully agree with you (from a 40 yo). I really love the term "technical debt", because it says exactly what it is, and can be communicated properly to management. As long as you have debt, you will keep paying for it until you pay it off. Very clear and precise, love it!
Refactoring a bit less, but it is also a very clear term so other people know what you are doing.
I think a lot of this is just a product of the amount of complexity software is expected to manage. No single person can keep it all in their head with all the constantly changing parts.
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.
> the amount of complexity software is expected to manage.
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?
The best way to think of Agile is "bare minimum project management for the sake of product management". You can get wrapped up in the rituals and "best practices" but at the end of the day, it's usually about delivering software in a way that makes it easy to buy and sell. It's easier to sell software when you can pull a feature on a roadmap up to land a big account than it is to refactor and cut a custom release for them. It's easier to buy software when you know it's constantly improving.
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 easier to sell software when you can pull a feature on a roadmap up to land a big account
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.
> 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.
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.
> 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.
I think everyone wistfully pining for an era without Agile forgets how many software projects were flat-out abandoned without seeing release after a few years of dev work. Software development was not a "hot profession" until Agile came along and a software product was no longer a multi-million dollar commitment to get money coming in the door. We all owe the success of the industry to Agile / iterative development, because most of the projects that keep us employed never would have gotten off the ground in a pre-Agile world.
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).
I am strongly sceptical about Agile bringing about software development to be the highly paid and somewhat prestigious profession it is today. I think it was more like the pressure to have software do much more than it did before.
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.
Unfortunately some decent points are somewhat obscured by the condescending and nostalgic tone that hits you in the first line:
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.
>Every generation has blinkered old guys talking in that way, who can safely be ignored.
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...
The Beatles: Firstly, you don't know what I know from my youth. Please argue the point, not your presumption of my personality. He talks about them as the heros of "our generation". They weren't. The musical heros of that generation (in the sense of being the leaders of that time) included the ones I've mentioned. The tone is nostalgic and rockist, as dull and unimaginative as his tone when talking about coding.
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.
>The Beatles: Firstly, you don't know what I know from my youth. Please argue the point, not your presumption of my personality.
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.
>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.
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.
People working on laptops like in that picture is unergonomic and unsustainable. Say hello to back- and neckpains. Who pays for that?
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.
You can synchronize with others' work without breaking flow. In a software dev context, computer-mediated communication and review, proper issue tracking, etc. make this a lot more feasible.
This can be true, though so can collaboration in person also be. Often, time pressures, office politics, culture, etc. get in the way, though can be filtered to some extent through text media, but not without losing some meaning, insights and opportunities.
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.
"The PMs were worse, putting on a perky, chirpy and cheerful show of sounding “engaged,” when in reality I knew they spent most of their day playing games..."
While I agree on a couple of things: Primarily how scrum and company are complete bastardization of everything the manifesto stood for and that the tall poppy syndrome against more dedicated developers by pretending they're not "team players" or are "prima donna"s is absolutely ridiculous; that's where my agreement ends.
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.
Bit rambling, but it boils down to a critique of fad-driven management: we have do TDD, Agile, whatever, but --from the developer's point of view-- more as an end than a means.
I've also been in software for many years. If I wanted to take aim at stupid corporate America (when/where it exists) in software it's pretty easy to be more damning than slashing agile's tire and running away. Btw we should acknowledge that while hw gets cheaper and better, sw has real problems doing the same. A better way to start don rickling software would be to start with the Standish choas report from the 90s.
The good thing about industry standard terms is that it makes it easier for people to work together. As opposed to everyone coming up with their own terms for things. To me that’s one of the big pros about agile.
I'm not sure if it is better to have everyone use different terms for the same things, or for everyone to use the same terms for different things. With Agile, I feel like we are mostly in the second case...
'Flow' is the faddiest word in Software Development right now. My entire company has managers talking about flow and rearranging time so that Engineers can flow etc.
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.
I work in the educational space, and I think, as education is discovering, different strokes for different folks. Different people learn best in different ways. Different people work best in different ways.
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.
What I took from the article is that he disliked the "morning standup" because it forced him through a rush hour traffic, compared to previous situation.
Sounds like the early morning standups are for the manager's convenience more than the coder's, which might be the underlying trend driving OP's complaints.
Just to be clear: in a not-so-distant future, some little shit is going to be describing why people like you aren't going to be missed, so be kind.
He actually makes some excellent points around challenging fad-driven-management, open office spaces, dorm culture instead of prioritizing flow, and what I see as a legitimate perspective on TDD's unfortunate tendency to reinforce blindspots. It's just a shame that he also sounds a bit like Hunter Thompson, shooting at cars passing too close to his compound.
For the record, one thing he's absolutely correct about is this idea that being able to handle all aspects and dimensions of a complex project is somehow arrogant and/or anti-social and/or dinosaur-esque.
I mean, I don't know anything about you but people who can competently build impressive shit solo command my respect. Your disbelief that such a thing can be extraordinarily valuable is just projecting a lack of confidence or imagination.
To be clear: not everyone will (or should) go there... but it's your prejudiced rejection of the possibility as gauche that pets me backwards. You are not the first or only generation to have everything all figured out.
Solo warriors are not that unique, just look at most of the successful one-man free software projects. Thing is, you can't expect them to turn up in your team. These "fad" processes help to cultivate their oversight in a reproducible, proveable manner. Also, processes are a toolbox, and managers can be good or bad. This does not deduct from the value of the processes.
Csikszentmihalyi is not respected by professionals of his field (there is no enthusiasm to followup on Flow). Of course Flow was also cargo cult executive catnip back in the day -- I suppose Mr. Fox's day.
> ...People like him aren't going to be missed. Their arrogance of not needing teams, being able to handle projects completely by themselves ....
Large-scale software projects were definitely around in the 1980s and 1990s including at M$, so it can't be that. The thing about "teamwork", recurring meetings/standups and other drains on 'flow' and individual productivity, is that they are a cost of your chosen development model. They're things you're supposed to minimize wherever feasible by improving your toolset (e.g. good repository management, CI, static analysis tools to cut down on pointless "unit" testing, computer-mediated communication as opposed to doing everything in person, etc.), not expand until they take up all available resources.
> He's describing Microsoft in a time where they didn't deliver any quality product at all. They didn't in the 80s, not the 90s or 00s.
What are you talking about? Windows 95, 98, 2000 and XP were all best in class, and only several years apart each. Seems like an amazing period.
I dislike the agile terminology because it’s so condescending. Your users have “stories”, it implies they’re fictional and not to be taken seriously. It’s dehumanizing.
> Windows 95, 98, 2000 and XP were all best in class
I know some OS/2 fans who wouldn't go along with that, but I will. They were best in a class that was inundated with crippling bugs and vulnerabilities. Can we credit checklists and pair programming for the fact that it's now possible to connect to the Internet without joining a botnet within 5 minutes? Or save a file without worrying whether it will make it to disk before the next BSOD? Probably not directly, but procedures and conventions definitely needed to change.
Really? Stories can't be nonfiction? I don't see that implication at all. Ever hear the story of Albert Einstein on the train? Galileo's trial? The sinking of the Titanic?
Anyway, other reasons to like it being called a story
* Stories require two people, a teller and a listener.
* Stories have an ending.
* Stories are relatable to people who otherwise might not know they care about your product
* The user is the hero of the story (i.e. the developer is the opposite of condescending by putting others first)
> Windows 95, 98, 2000 and XP were all best in class, and only several years apart each. Seems like an amazing period.
Haha, great joke. Oh wait you are serious? The amazing blue screens made me switch to Linux in that period. And if you knew about the state of Linux back then, that says something about this "best in class"
He is spot on.
Not that everything is worse today.
There are things that are a lot better these days.
But this all goes in cycles. Human progress is not a continually improving thing. In many areas we sometimes go backwards for a while before it reverses again. One major driver for this is closemindedness. Rejecting the past without even considering its validity. In a little over twenty years from now just look around for that twenty year old programmer, not even born yet, who will be leading a new generation of programmers who will be mocking you as that "Get off my lawn guy" with the old fashioned obsolete old school ways. They will be pushing what they think are brand new ideas but are actually a variation of the 1980's and 1990's.
But in the long run this constant turnover of fads does result in a solid body of knowledge of what works and what does not work.
For instance a continuous recorded history of Chinese Cooking over the last 5000 years is an invaluable resource for exploration and inspiration for new ideas.
Meanwhile, there are other 40+ programmers like myself who still enjoy themselves with the latest tech, fads, open offices, lots of communication and fellow young programmers.
Programming nowadays has improved so much it's crazy.
- Have a problem? 99% chance your answer is on StackOverflow. (anyone remember the days before internet? I do! Searching (alone) hours on some cryptic error message)
- Programming robots is so easy and cheap nowadays.
- Everyone walks around with a super powerful computer, integrated GPU, camera, GPS, gyroscope and internet ready wherever you go.
- So much powerful stuff available for free.
- Current IDE's have so much handy functionality.
- Make your software available to the world in an instant. Want to run your own server software? So easy and cheap!
So yeah, grumpy old programmers still exist. But I also know plenty of old programmers who love all the new stuff.
Personal attacks are not ok. We ban accounts that post them. Maybe you don't owe the person better, but you definitely owe this community better if you're posting here. Would you mind read the site guidelines and taking the intended spirit to heart? We'd appreciate it.
...look at all the babylon fans cheering the monster on. how dare a measly lowly human have an opinion after personally suffering at the hands of brainless machinery...
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.
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.