What Happened to Software Development?(hackernoon.com)
hackernoon.com
What Happened to Software Development?
https://hackernoon.com/what-happened-to-software-development-j92032w9
94 comments
>> ... play my guitars ...
Nah, he's just a literal rockstar programmer. You've got to give him that.
Nah, he's just a literal rockstar programmer. You've got to give him that.
way to cheer for babylon, my future grumpy old fart in waiting...
Agree.
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.
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...)
"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.
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.
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.
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!
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.
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.
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.
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.
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.
- 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.
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.
this.
and ultimately, who PAYS for all these deliberate hurdles and the deliberate curtailing of human productivity to serve a tangential dubious (at best) goal?
and ultimately, who PAYS for all these deliberate hurdles and the deliberate curtailing of human productivity to serve a tangential dubious (at best) goal?
Seems like a proof by existence about the predominance of BS jobs?
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 [...]
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.
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.
EDIT: I'm apparently a blind idiot in the morning. Misread the parent comment.
It seems autocarrot did not only change one word in the beginning your text but fittet the rest of your text to find a new meaning.
My eyes don't work this early apparently. I completely misread the comment I responded to.
"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.
Refactoring a bit less, but it is also a very clear term so other people know what you are doing.
I guess those idiots in the 70s who built UNIX, who didn't use the terms "refactoring" and "technical debt" were also clueless.
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.
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?
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.
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. 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.
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.
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).
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.
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.
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...
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.
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.
>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.
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.
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.
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 assume it's a library and not people working. that would be terrible
No, that's the state of the art these days. You don't even have an assigned desk, you have to battle for prime real estate. Every day.
Only the fittest survive, and no disability checks for the poor.
I'm totally ok with Standups as long as they're not every day.
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.
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.
He is 100% right about flow. 8 hours of super quality concentrated high value work with breaks is what everyone wants but no one gets.
"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..."
Ayup....
Ayup....
[deleted]
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.
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.
I love the look of the house.
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.
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.
[deleted]
[deleted]
I hope younger devs keep in mind that one day you will be the "old" one.
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...
Usually the funniest thing about these posts is some kind of implication and surprise that things would have stayed the same across generations
'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.
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.
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.
[deleted]
Agreed 100%.
yesyesyesyesyes
agree 1,000,000%
agree 1,000,000%
lovetocode(1)
jasonvorhe(11)
ddek(1)
...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.
where does the true arrogance actually lie?
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?
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.