> 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.<p>This is someone who prefers solitude. It's not surprising that he doesn't like collaborative work.<p>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).<p>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.<p>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).<p>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).<p>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.
What's up with the pair programming hate? I think it is great in the correct situations and would love to do more of it!<p>1. Get paired with another dev of similar level to work on new stuff. Bouncing ideas makes the surfacing solutions better.<p>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.
In my (probably worthless) opinion, the two big problems affecting software industry are:<p>- 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.<p>- 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 <i>wanted</i> to.<p>The second problem is actually a big part of the cause of the first.<p>Perhaps I'm just bitter, but given the abundance of technologies, frameworks, libraries, services, etc, small teams of <i>good</i> 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.<p>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 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:<p>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!<p>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.
"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.
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.<p>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 <i>some</i> dev jobs, but <i>most</i> 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.
Unfortunately some decent points are somewhat obscured by the condescending and nostalgic tone that hits you in the first line:<p><i>Many too young to have ever seen the halcyon days of software development...</i><p>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.<p>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 <i>Nirvana</i>. Or <i>Wu Tang</i>. Whatever, he sounds like he was always looking back.
People working on laptops like in that picture is unergonomic and unsustainable. Say hello to back- and neckpains. Who pays for that?<p>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.
I'm totally ok with Standups as long as they're not every day.<p>I like working remote but I also like working in the office a couple days a week to connect with my team members.<p>It's possible that these ideas taken to the extreme are bad but taken in moderation can be great.<p>Open offices...are still the most horrible idea ever.
<i>"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..."</i><p>Ayup....
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.<p>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.<p>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.
I love the look of the house.<p>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.
'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.<p>It completely ignores that masses of people do not work effectively that way.<p>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.
...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...<p>the thing is, it takes exactly zero courage or risk to cheer for the status quo.<p>the other thing is, later we often realize that the system was wrong, and the iconoclast was right.<p>where does the true arrogance actually lie?