Speed matters: Why working quickly is more important than it seems (2015)(jsomers.net)
jsomers.net
Speed matters: Why working quickly is more important than it seems (2015)
http://jsomers.net/blog/speed-matters
36 comments
Efficiency is also more important than it seems. You can have lots of low quality, half-baked output. How much forethought do we put into what we will work on to begin with? Some projects and ideas are not worth the effort. Or an alternative solution to a problem is preferable over one you’ve been hammering away at for days, and would be easier to implement.
And in the realm of programming, it’s often easy to take shortcuts even though later on they wind up costing more time for you or others involved: omitting documentation, not making something reproducible, poor code quality, etc.
Having spent most of my career in academia I see a lot of the work makes this trade off: efficiency is sacrificed for a sloppy, immediate “speedy” solution. You need to find a balance and think through problems, considering not only what is immediately in front of you but also what you’ll be doing in a month or year. Otherwise you’ll wind up with a project or codebase that begins to drag your productivity and output with it.
And in the realm of programming, it’s often easy to take shortcuts even though later on they wind up costing more time for you or others involved: omitting documentation, not making something reproducible, poor code quality, etc.
Having spent most of my career in academia I see a lot of the work makes this trade off: efficiency is sacrificed for a sloppy, immediate “speedy” solution. You need to find a balance and think through problems, considering not only what is immediately in front of you but also what you’ll be doing in a month or year. Otherwise you’ll wind up with a project or codebase that begins to drag your productivity and output with it.
Not every product is maintained for years. In many cases it's good to be able to choose between a quick solution and a good solution, as long as these are concious decisions and some record of accrued technical debt is kept.
Rarely if ever in the beginning of the project it's 100% sure or guaranteed how long the project will be maintained. There might be some estimates, but in the long run upper management might change their minds at any time and then you are fucked if you didn't build robust architecture from the start.
At least according to my experience and everyone I know in the industry.
At least according to my experience and everyone I know in the industry.
But there are so many counterexamples to that too. I worked on a project following CI practices with a release every two weeks, and I can think of plenty of examples where we developed a feature, tested it with users, and scrapped it within a month. That team leaned toward strict practices, and we wasted so much time on code review and documentation of small details which only existed for a couple of weeks.
I also thing it is vastly overstated how difficult it is to incrementally refactor a project which is "fucked". It's always possible to break it into smaller pieces, and gradually improve the codebase until it is manageable and easy to work with.
I also thing it is vastly overstated how difficult it is to incrementally refactor a project which is "fucked". It's always possible to break it into smaller pieces, and gradually improve the codebase until it is manageable and easy to work with.
I also thing it is vastly overstated how difficult it is to incrementally refactor a project which is "fucked". It's always possible to break it into smaller pieces, and gradually improve the codebase until it is manageable and easy to work with.
What if there's no automated testing worth a damn, and the penalty for a bug is very high? Been there, done that, and I have to say, you don't ever want to stay there!
What if there's no automated testing worth a damn, and the penalty for a bug is very high? Been there, done that, and I have to say, you don't ever want to stay there!
The question is, if the project you worked would be a mess from the beginning, would it allow your company to test and scrap features fast?
Yes, it's possible, but at what cost? E.g. long hours, unhappy devs, implementation taking too long.
Yes, it's possible, but at what cost? E.g. long hours, unhappy devs, implementation taking too long.
The point is there's a balance. I think it's perfectly reasonable to allow a certain amount of technical debt to accrue, especially when prototyping new features, and treat it as a priority to clear this debt by the time said features become a dependency to other parts of the project.
It takes a bit more nuance to get a team to work that way rather than just enforcing Best Practice(tm) always, but in my experience it can be much more productive overall.
It takes a bit more nuance to get a team to work that way rather than just enforcing Best Practice(tm) always, but in my experience it can be much more productive overall.
I think it's perfectly reasonable to allow a certain amount of technical debt to accrue, especially when prototyping new features, and treat it as a priority to clear this debt by the time said features become a dependency to other parts of the project.
The point of code quality is to enable the company to change its mind or add new features. Over-perfectionism that gets in the way of this is going too far. At one company I worked for, the policy was not 100% strict DRY. Instead, we waited for 3 uses of the same idiom before we put it in the library. This prevented the collection of too many trivial methods, while still giving the benefits of DRY.
The point of code quality is to enable the company to change its mind or add new features. Over-perfectionism that gets in the way of this is going too far. At one company I worked for, the policy was not 100% strict DRY. Instead, we waited for 3 uses of the same idiom before we put it in the library. This prevented the collection of too many trivial methods, while still giving the benefits of DRY.
Smart devs know they probably get the abstractions wrong until the third iteration. This sounds like a sane policy.
If you work on legacy code you can be sure that your code will be used for years if not decades.
Legacy code often ends up as such, because it was immediately available and immediately utilized. It worked then, and piled on functionality.
You don't see good looking legacy, because it didn't survive.
You don't see good looking legacy, because it didn't survive.
Often, the difference between a quick solution and a good solution isn't technical debt! (So long as there isn't an impediment to adding them in the future.) Missing features aren't technical debt.
Technical debt manifests in a code base, most generally as various forms of pain that occur when trying to add features. That's how the company "pays interest" on the technical debt. Coding so that you can always change your mind, however that is accomplished, is the key there. (This is one place where the "Law of Demeter" really shines!)
Technical debt manifests in a code base, most generally as various forms of pain that occur when trying to add features. That's how the company "pays interest" on the technical debt. Coding so that you can always change your mind, however that is accomplished, is the key there. (This is one place where the "Law of Demeter" really shines!)
I think it's somewhat paradoxical: The software that gets delivered, produces value gets to live. The market prefers just-good-enough software
There is also a possibility that your predictions about the future turn out to be wrong.
It's definitely a balancing act.
One extreme is always going for the instant gratification, paying no attention to how things fit into the overall design.
The other extreme is trying to design everything up front with no feedback and getting more and more divorced from the practical reality as time without implementation goes on.
It's definitely a balancing act.
One extreme is always going for the instant gratification, paying no attention to how things fit into the overall design.
The other extreme is trying to design everything up front with no feedback and getting more and more divorced from the practical reality as time without implementation goes on.
Even worse, the correct balance depends on the project. Sometimes everything around you is well understood and set in stone; in that case it's beneficial to plan meticulously ahead. In other cases everything is in flux and nobody knows what the requirements even are; then you just have to incrementally build towards a solution with frequent refactoring. But knowing where on that spectrum you are is crucial.
When I feel progress goes slow, or a task is too hard, I will use test driven development: Just implement the bare minimum in order to make the test pass, basically dividing the task up into many small steps.
When I do dev stuff with a slight sense of urgency, the probability of my mind wandering somewhere else goes down drastically.
At this mode, my mind uses all available time slots to make the best of them. For example, by the time my program compiles, my brain visualizes possible breakage scenarios and possible solutions, in case the compilation fails.
I could be on confirmation bias here, but this seems to be a neat trick to get more things done.
At this mode, my mind uses all available time slots to make the best of them. For example, by the time my program compiles, my brain visualizes possible breakage scenarios and possible solutions, in case the compilation fails.
I could be on confirmation bias here, but this seems to be a neat trick to get more things done.
Yeah, but could it also increase risk of stress, anxiety, burnout?
You can overdo it, but just my personal experience is that focus on work at work, even with urgency, never brings those.
Where anxiety and stress can come in for me is letting unsolvable, abstract-ish things hound me for a long time: "I have made a big mistake in life N years ago", etc.
Where I think urgency is hurting is breadth: I focus only on the easiest solution and long term view goes out the window so I need to intersperse walking or similar to let my mind wander to strange, stupid or potentially good ideas. Just my 2c, YMMV.
Where anxiety and stress can come in for me is letting unsolvable, abstract-ish things hound me for a long time: "I have made a big mistake in life N years ago", etc.
Where I think urgency is hurting is breadth: I focus only on the easiest solution and long term view goes out the window so I need to intersperse walking or similar to let my mind wander to strange, stupid or potentially good ideas. Just my 2c, YMMV.
True. Too much of anything is bad. I keep this mode on for as long as I don't get mentally tired. Usually, that's a span of 2-3 hours.
Surprisingly, at the end of the day (typically after two/three of these zones) I feel more fresh, satisfied and productive. But that's just me.
Surprisingly, at the end of the day (typically after two/three of these zones) I feel more fresh, satisfied and productive. But that's just me.
Too much multitasking and producing software for years has made me feel this weird thing:
Which is that all accomplishments are meaningless in the end. And we are just getting older. Once a person dies they aren’t experiencing any stuff that came as a result of their effort. They may as well have just messed around and had a family sooner, or traveled, or not. It’s all meaningless anyway.
I can’t shake it. Anyone felt this way all the time? Any advice?
Which is that all accomplishments are meaningless in the end. And we are just getting older. Once a person dies they aren’t experiencing any stuff that came as a result of their effort. They may as well have just messed around and had a family sooner, or traveled, or not. It’s all meaningless anyway.
I can’t shake it. Anyone felt this way all the time? Any advice?
Yep. The thought process you describe came on hard once I actually had my first child. The tech that dominates today is just pushing bytes from client to server in the pursuit of some business person's perception of value for the fleeting moment - all we write is dust in the wind. Failing getting a the chance to work on some truly novel technology or research, my next work move will be a big company where work hours and load is better respected.
There are amazing people out here on HN who can help you with better answers to the question. Why don't you post an Ask HN and see? Or better talk with people in person about this.
As for me, Yes, I might pick traveling and having fun over creating software. But I'm not from a wealthy background and my need for a better quality of life is satisfied by selling my skill for money. In that sense, I picked long-term quality of life over short bursts of fun and happiness.
Also, I do have fun coding so it's kind of alright for me.
As for me, Yes, I might pick traveling and having fun over creating software. But I'm not from a wealthy background and my need for a better quality of life is satisfied by selling my skill for money. In that sense, I picked long-term quality of life over short bursts of fun and happiness.
Also, I do have fun coding so it's kind of alright for me.
I used to feel this way, a little bit. Then I had a family and was glad to have the financial security to provide for my family compared to so many others.
So, consider your heirs, and work long enough to build a nest egg cushion the devote time to having a wonderful spouse, making babies and enjoying them.
So, consider your heirs, and work long enough to build a nest egg cushion the devote time to having a wonderful spouse, making babies and enjoying them.
Note this advice won't apply for people who aren't interested in starting families. Even for those in happy marriages, not everyone feels that biological itch to have kids. And not everyone even feels the itch to marry.
Same here. It's not a biological itch for me, it's a desire to leave/change something for this world. In my case, it's [adoption|stepkids|nieces|nephews].
+1 for the money, sex and progeny checklist
Yes, this is a valid way of considering life. I'm personally not that into travel or starting a family, so I just replace the "might as well have just" to fit my own interests.
I think starting your own project or startup can fall into that category, too. It can be very intrinsically fun and rewarding, and the idea is to do stuff that's intrinsically fun and rewarding while we're still alive, I think. Writing 2.0 of BigCorp's latest TPS management app carries none of that, and so it seems like a complete waste in the grand scheme of life.
Another option is to do things that really will have a significant positive impact on people's lives post-death, and despite the fact that you won't be able to see, feel, or appreciate the impact you caused after you die, it will still feel very worthwhile for the entire duration that you're still alive. Like helping fight global hunger or disease, for example. You'll forget that TPS 2.0 app a few days after you've quit that job probably, but if you quit a non-profit helping fight hunger and you made something that actually tangibly helped, you'll probably think about that your whole life.
I think starting your own project or startup can fall into that category, too. It can be very intrinsically fun and rewarding, and the idea is to do stuff that's intrinsically fun and rewarding while we're still alive, I think. Writing 2.0 of BigCorp's latest TPS management app carries none of that, and so it seems like a complete waste in the grand scheme of life.
Another option is to do things that really will have a significant positive impact on people's lives post-death, and despite the fact that you won't be able to see, feel, or appreciate the impact you caused after you die, it will still feel very worthwhile for the entire duration that you're still alive. Like helping fight global hunger or disease, for example. You'll forget that TPS 2.0 app a few days after you've quit that job probably, but if you quit a non-profit helping fight hunger and you made something that actually tangibly helped, you'll probably think about that your whole life.
If you focus on yourself as individual, your are limiting yourself to your lifespan, and sure everything seems meaningless in perspective.
Think of yourself as a part of humankind - you can contribute big or small to the goal of continuing the existence of humankind and its further expansion - with your work, raising children, other.
Ultimately, there is no meaning given to us from any source (given that you are not religious), and you search and choose your own.
Think of yourself as a part of humankind - you can contribute big or small to the goal of continuing the existence of humankind and its further expansion - with your work, raising children, other.
Ultimately, there is no meaning given to us from any source (given that you are not religious), and you search and choose your own.
Just do what you want/enjoy doing and stop worrying.
Sounds a bit like the Pomodoro method: focus intentionally for short periods, and then rest intentionally for even shorter breaks. It's a bit like interval training for the brain.
I've been wondering if 20 minutes of coding in 'urgent mode' then a 5 minute break, repeated, with a lunch break, would be more productive than 'average mode' all day, and without the burnout.
Try it and let us know - it's different for many people. I can work weeks at 14 hours a day without more than brief bathroom/food breaks if I'm passionate and not distracted.
Yeah I never feel that passionate when someone is paying me to work. Motivation is a funny thing.
I’m that ‘deadline bring me creative juice’ type of person. I’d say it kind of work to certain degree from my experience — good solution popup out of nowhere, maybe because like you said, I am very focused on that work alone, and nothing else.
It obviously doesn’t sustainable though, both your work and health. It get a job done, but I know that it lack finesse quality, also all that stress definitely shorten my lifespan.
It obviously doesn’t sustainable though, both your work and health. It get a job done, but I know that it lack finesse quality, also all that stress definitely shorten my lifespan.
Same thing happens to me, but not only on dev stuff. You get into "Flow" state.
For me, after years producing software, I've set myself up to be able to say no.
I disregard urgency when it exists for urgency's sake, coming out of business despair or a gut feeling. I will gladly work for 2 - 3 months on hyper mode, giving away my mental and physical health for a feature that will actually provide business value and for which the business can make a good case for why it's needed yesterday.
Working with multiple companies on executive and / or consulting levels, I feel like a lot of business rush is done because business 'needs it now' in the hope that it will improve the bottom line because it's easier to expect a miracle than it is to take a good look at your fundamentals.
The businesses with the most solid foundation I find are the ones that rarely need to rely on speed and instead rely on quality and produced value... once in awhile, a feature idea comes up that can propel the company - especially in the face of competitors - and it needs to be done as fast so that the producer can get as much value out of it before the competition catches up. That's a good reason to expect speed.
Today's society expects hyper growth, hyper speed, hyper scale, but that is because this is what is mostly advertised and we as humans have a tendency to expect the world to work as is advertised, when in reality, there are a lot of smaller companies that don't create anxiety filled working days for their employees.
I disregard urgency when it exists for urgency's sake, coming out of business despair or a gut feeling. I will gladly work for 2 - 3 months on hyper mode, giving away my mental and physical health for a feature that will actually provide business value and for which the business can make a good case for why it's needed yesterday.
Working with multiple companies on executive and / or consulting levels, I feel like a lot of business rush is done because business 'needs it now' in the hope that it will improve the bottom line because it's easier to expect a miracle than it is to take a good look at your fundamentals.
The businesses with the most solid foundation I find are the ones that rarely need to rely on speed and instead rely on quality and produced value... once in awhile, a feature idea comes up that can propel the company - especially in the face of competitors - and it needs to be done as fast so that the producer can get as much value out of it before the competition catches up. That's a good reason to expect speed.
Today's society expects hyper growth, hyper speed, hyper scale, but that is because this is what is mostly advertised and we as humans have a tendency to expect the world to work as is advertised, when in reality, there are a lot of smaller companies that don't create anxiety filled working days for their employees.
>I will gladly work for 2 - 3 months on hyper mode, giving away my mental and physical health for a feature that will actually provide business value and for which the business can make a good case for why it's needed yesterday.
I feel sorry for you.
As some who's been around the block a few times, I will never, EVER, give away my mental or physical health for someone's business.
My health is more important than their quarterly targets.
I feel sorry for you.
As some who's been around the block a few times, I will never, EVER, give away my mental or physical health for someone's business.
My health is more important than their quarterly targets.
In defense of the parent, I can imagine a situation where I'm excited and truly bought into a product as improving peoples lives and am willing to expend the energy to dramatically improve that product in meaningful ways. I think this is something a lot of folks in our industry want, and that's not per se bad though it can lead to negative outcomes.
I had a project like this once. I really threw myself into it. I wasn't dying, but it did have a negative impact on my life in most other dimensions.
Then some kind of politics held the project up (likely for years), and they had me work a different project, so I quit, 'cause it was the success of that particular project that had me coming to work (it was gonna prevent traffic accidents, and it was fun to work on).
I have a healthier work/life balance now, but I don't care about what I'm working on. If they could get the wheels moving on that project again I'd switch back in a heartbeat.
I'm gonna die either way. If I have to put in a bit more work in order for it all to have meant something more than pointless meetings and products that nobody wants, then that's work I'm willing to do.
Then some kind of politics held the project up (likely for years), and they had me work a different project, so I quit, 'cause it was the success of that particular project that had me coming to work (it was gonna prevent traffic accidents, and it was fun to work on).
I have a healthier work/life balance now, but I don't care about what I'm working on. If they could get the wheels moving on that project again I'd switch back in a heartbeat.
I'm gonna die either way. If I have to put in a bit more work in order for it all to have meant something more than pointless meetings and products that nobody wants, then that's work I'm willing to do.
One of the rare instances in which I threw myself into those sprints I was advocating for is working on the national emergency management system. I loved the project, I felt like my contribution to society was well worth the months spent sweating over it. Childless, young and healthy, it was a great experience and I still check the uptime from time to time a lot of years later.
I've since left that institution precisely for what you mention, politics, and exactly like you I something think about working on that project again. I don't think any project I'll ever work on will be as satisfying from a societal perspective, as that one.
I've since left that institution precisely for what you mention, politics, and exactly like you I something think about working on that project again. I don't think any project I'll ever work on will be as satisfying from a societal perspective, as that one.
Thank you for the defense, it's exactly the kind of situation I'm arguing for.
I think it's also important to note the context of who is doing this kind of sprints. Does he have a family? Does he have other engagements? Does he have other health issues?
It's not for everyone, but I believe in my case, timing them properly, recovering properly afterwards and reaping the benefits has worked in my favor.
I might have given the impression that I am advocating for regular such sprints when in fact I have done this rarely, at pivotal moments, with years in between them.
I think it's also important to note the context of who is doing this kind of sprints. Does he have a family? Does he have other engagements? Does he have other health issues?
It's not for everyone, but I believe in my case, timing them properly, recovering properly afterwards and reaping the benefits has worked in my favor.
I might have given the impression that I am advocating for regular such sprints when in fact I have done this rarely, at pivotal moments, with years in between them.
This is giving money to the rich. Don’t put in any more time than you need to; no product is worth that.
The rich put money in and they get money out, myself I can only sell my services and when I truly believe in something to see that it is implemented to the best of my abilities.
I will always look after my own health and will always try to maintain control, but each of us has his own context. "No product is worth that" is a general statement that might not apply to everything and everyone.
I will always look after my own health and will always try to maintain control, but each of us has his own context. "No product is worth that" is a general statement that might not apply to everything and everyone.
It's not a war. The rich are to be feared and pitied, like all humans.
>It's not a war. The rich are to be feared and pitied, like all humans.
Fear and pity them all you want, but your health is not theirs. Don't give away the only thing you truly have, and the only thing you can never really get back.
Fear and pity them all you want, but your health is not theirs. Don't give away the only thing you truly have, and the only thing you can never really get back.
[deleted]
This culture of sacrificing everything for the bottom line is a cancer on our industry.
Yeah that's a junior mistake. In this case, a person can have a solid 20+ years of great career and still do this basic mistake. World is full of people rich and poor, smart and not so much, who end up regretting their life choices when getting old.
I would say it differently though - do I have +-guaranteed massive return that over-compensates my extra effort and loss? If I get something meaningful, ie paid next 5 amazing vacations, can retire 1 year earlier, pay off massive part of mortgage or something on similar level, then I can at least consider it.
I would say it differently though - do I have +-guaranteed massive return that over-compensates my extra effort and loss? If I get something meaningful, ie paid next 5 amazing vacations, can retire 1 year earlier, pay off massive part of mortgage or something on similar level, then I can at least consider it.
Potentially unpopular opinion but I agree. If there's a definite payoff to burning hard on a given project, I'll do it. Trading a few months or weeks for a paid off home is hardly insane at all.
I feel both sorry for the parent and also relate to it. I have several sprints a year that get me so excited about work, that I will head to work after kids’ bedtimes to code — all night — because I can’t stop thinking about some solution. Sometimes I’m so excited I wouldn’t be able to sleep so might as well work.
Why do you do that for a company that would be throw you away if it made economic sense to do so?
Why don't you find personal avenues in which to exert that creative energy for you, your family, or society?
Why don't you find personal avenues in which to exert that creative energy for you, your family, or society?
In many ways, it is actually a very selfish decision on my part as an Engineer -- I'm doing it because i'm thrilled with my job, the product I work on (and launched) and cant stop thinking about some of the Engineering problems I encounter -- because they are so fascinating.
My current employer is shrewd in that they have aligned their interests to mine -- they have moved away most of the BS typical of engineering jobs. They have other people do the parts I don't enjoy doing, and they have given me wide latitude in Product and Product Engineering decisions. They have also given me wide latitude on task selection -- which tasks I take and which get assigned to others on my team (or others on other teams.) This isn't a constant state, it happens on several sprints a year.
On a side note, yes, I exert lots of creative energy in other domains. I'm on the board of a non-profit mentoring org, I'm an advisor to a nature conservancy organization, and I spend a huge amount of time with my family and children.
When I was single, I was part of a community food cooperative and several educational mentoring orgs. Now, the lions share of free time goes to children.
Side note -- if/when my employer turns into Initech and I'm filling out TPS Reports, you can be sure I'll be clocking out at 5pm.
My current employer is shrewd in that they have aligned their interests to mine -- they have moved away most of the BS typical of engineering jobs. They have other people do the parts I don't enjoy doing, and they have given me wide latitude in Product and Product Engineering decisions. They have also given me wide latitude on task selection -- which tasks I take and which get assigned to others on my team (or others on other teams.) This isn't a constant state, it happens on several sprints a year.
On a side note, yes, I exert lots of creative energy in other domains. I'm on the board of a non-profit mentoring org, I'm an advisor to a nature conservancy organization, and I spend a huge amount of time with my family and children.
When I was single, I was part of a community food cooperative and several educational mentoring orgs. Now, the lions share of free time goes to children.
Side note -- if/when my employer turns into Initech and I'm filling out TPS Reports, you can be sure I'll be clocking out at 5pm.
You are making a lot of assumptions here. Not all companies are bad or will throw you away. Maybe they are friends or family with the owner? In that case, helping the company bleeds outside of just an economic decision.
I didn't use the term "bad". I said it was based in economics.
It's called a work/life balance. Work, and the related money are a means to being able to live in this society. And how we choose to use the money and power, is how we affect society. But running to work after everyone else "goes to sleep" doesn't appear as a healthy relationship.
And I know of nobody who said when they got old, "I wish I spent more time at work".
It's called a work/life balance. Work, and the related money are a means to being able to live in this society. And how we choose to use the money and power, is how we affect society. But running to work after everyone else "goes to sleep" doesn't appear as a healthy relationship.
And I know of nobody who said when they got old, "I wish I spent more time at work".
But you're making the assumption that "work/life balance" must happen at the daily level. I'm perfectly happy to work my ass off for a couple months and then take a month off. To me that's a far better balance than trying to fit it all within a day.
Answering as you are referring to my post. The kind of sprints I'm advocating for are few and far in between and shouldn't be taken lightly.
Yeah, that sentence leapt out at me too. Bizarre life priorities, and undermines otherwise sensible remarks.
Happy to be a slave as long as it makes me feel good.
You're willingly choosing to work on an interesting problem that you otherwise would not have access to, and, let's be real, our compensation and autonomy as developers is far from that of servitude. Plus you can quit any time.
Slavery here really hyperbolic. We're talking about hard work that is both interesting and rewarding.
Slavery here really hyperbolic. We're talking about hard work that is both interesting and rewarding.
>We're talking about hard work that is both interesting and rewarding.
Your hard work is way more rewarding to your masters than to you, though.
Your hard work is way more rewarding to your masters than to you, though.
We're all slaves man.
Yeah I get the sarcasm, but I really don't understand people who accept capitalism and also accept that their hard work is worth more than what they receive in compensation. Like, shouldn't they be upset and trying to find a way to twist the system for their benefit, just like the people using them?
I don't think most people have the mental bandwidth to balance rotting away in an 8 hour job, managing family life, and having some semblance of self esteem just to add on how to escape. I think the pressure release of the weekend is the only satisfaction people can afford due to the momentum of work completely eroding their concept of life.
There are plenty of people who do though I imagine.
There are plenty of people who do though I imagine.
I have peers who are DINKs who have openly embraced the idea of capitalism as a good thing. Yet they toil for someone else all day not getting paid for their output.
Capitalism isn’t about value of work: you aren’t paid for what you deliver. Free markets are about supply and demand: is someone else willing to deliver the same value for a lower cost.
We are all consumers behaving like this, looking for the best deals on products. Don’t expect employers to behave differently.
why did you transition from capitalism to free markets? I'm not sure I believe they are the same thing or are required to coexist in the same system.
Fair point, they are not the same. Reason to do this is because the parent mentioned not being awarded according to value, it seems to me his core problem is with the free market system, not so much with capitalism as a tool to organize power and politics.
I think I might have given the impression that I'm advocating for this kind of sprint as a regular occurrence when I'm actually advocating for very spaced out moments (the kind you can count on your hand in your entire career), well chosen and with the proper aftercare.
> I feel sorry for you.
I'm doing O.K., thank you for the concern.
> As some who's been around the block a few times, I will never, EVER, give away my mental or physical health for someone's business.
> My health is more important than their quarterly targets.
I wholeheartedly agree, however I believe there are some situations where such a choice is not so bad. If you're young, have no obligations, believe in what you do and will end up a lot better after the sprint, I think it's not such a bad thing. The most important thing I believe is being able to take the time off after said sprint to recover and get things back to normal. It shouldn't be a normality in your life and you should be in total control of the situation.
Also such sprints should be seriously spaced.
I'm doing O.K., thank you for the concern.
> As some who's been around the block a few times, I will never, EVER, give away my mental or physical health for someone's business.
> My health is more important than their quarterly targets.
I wholeheartedly agree, however I believe there are some situations where such a choice is not so bad. If you're young, have no obligations, believe in what you do and will end up a lot better after the sprint, I think it's not such a bad thing. The most important thing I believe is being able to take the time off after said sprint to recover and get things back to normal. It shouldn't be a normality in your life and you should be in total control of the situation.
Also such sprints should be seriously spaced.
>however I believe there are some situations where such a choice is not so bad. If you're young, have no obligations, believe in what you do and will end up a lot better after the sprint
How will YOU end up better after the sprint if you're not working on your own product but on your company's? That will benefit your CEO and shareholders for sure but how does it benefit YOU exactly?
Keep in mind, you have one health in your life and when it's gone it's gone for good whereas there'll be plenty of world-changing unicorns where you can work yourself to exhaustion if that's what you wish. Nobody has ever regretted on their deathbed not having worked more for someone else.
How will YOU end up better after the sprint if you're not working on your own product but on your company's? That will benefit your CEO and shareholders for sure but how does it benefit YOU exactly?
Keep in mind, you have one health in your life and when it's gone it's gone for good whereas there'll be plenty of world-changing unicorns where you can work yourself to exhaustion if that's what you wish. Nobody has ever regretted on their deathbed not having worked more for someone else.
Sure you can say that now, but have you ever worked in a recession?
ThalesX, your comment here is better than the linked article. Well said.
Looking back over the years of software development I've been involved in (jeez, 27) and remembering the things that were developed with all haste, not one of them, not a single one, met with success. There were some that were developed quickly, usually to meet contractual deadlines, that were good and gave the customer what they needed, but even then, if they could have just waited one more month, I think they would have gotten something better and been more successful.
Looking back over the years of software development I've been involved in (jeez, 27) and remembering the things that were developed with all haste, not one of them, not a single one, met with success. There were some that were developed quickly, usually to meet contractual deadlines, that were good and gave the customer what they needed, but even then, if they could have just waited one more month, I think they would have gotten something better and been more successful.
Thank you for the kind words.
If I may add this, I believe two forces are particularly strong when leading us to deliver rushed solutions. One is this expectancy of the market to ever grow, faster, stronger, harder. All. The. Time. The second is stakeholder focus on the short term and using estimates as deadlines to 3rd parties.
These forces get translated by business people into the classic 9 women can give birth to a child in 1 month situation which we can actually deliver because most of them can actually get even more value from being able to sell maintenance.
Hey, as long as lives don't get lost from shoddy implementations all is well; oh wait...
If I may add this, I believe two forces are particularly strong when leading us to deliver rushed solutions. One is this expectancy of the market to ever grow, faster, stronger, harder. All. The. Time. The second is stakeholder focus on the short term and using estimates as deadlines to 3rd parties.
These forces get translated by business people into the classic 9 women can give birth to a child in 1 month situation which we can actually deliver because most of them can actually get even more value from being able to sell maintenance.
Hey, as long as lives don't get lost from shoddy implementations all is well; oh wait...
> I will gladly work for 2 - 3 months on hyper mode, giving away my mental and physical health for a feature that will actually provide business value and for which the business can make a good case for why it's needed yesterday.
I felt the same way until I caused permanent damage to my eyesight from stress. It isn't worth it.
I felt the same way until I caused permanent damage to my eyesight from stress. It isn't worth it.
It seems like this should work the other way too? If you want to break a habit, add a delay.
This seems like a good idea for a browser extension. Maybe sometimes you want to undo the work that the website did making things go faster?
This seems like a good idea for a browser extension. Maybe sometimes you want to undo the work that the website did making things go faster?
That might be a really good idea. Over the years I've tried multiple website blockers, but I keep turning them off (no judgment please...).
Artificially slowing down those time waster websites instead might do the trick. Not so slow it becomes unusable (or I'll turn it off) , but slow enough that over time I start associating it with a bad experience.
Artificially slowing down those time waster websites instead might do the trick. Not so slow it becomes unusable (or I'll turn it off) , but slow enough that over time I start associating it with a bad experience.
Try LeechBlock (https://addons.mozilla.org/en-US/firefox/addon/leechblock-ng...).
It's been a lifesaver in tackling my internet addiction. It has the useful 'delay option' and other nifty features that helped wean me off social media sites.
Personally, I have it installed on all my desktop browsers and Firefox on Android. I give myself half an hour quota per day for the time waste websites (Youtube, Twitter, FB, Insta, etc) after which a 60 second delay rule kicks in. I've found that my monkey brain almost never bothers waiting for a minute for the page to load unless it's absolutely necessary.
It's been a lifesaver in tackling my internet addiction. It has the useful 'delay option' and other nifty features that helped wean me off social media sites.
Personally, I have it installed on all my desktop browsers and Firefox on Android. I give myself half an hour quota per day for the time waste websites (Youtube, Twitter, FB, Insta, etc) after which a 60 second delay rule kicks in. I've found that my monkey brain almost never bothers waiting for a minute for the page to load unless it's absolutely necessary.
The best amount of delay could depend on your goal.
One goal is to quit something completely. For that, you probably want delay across the board so that it eventually saps the joy out of the experience.
Another goal is practicing moderation. With social media as an example, maybe you want to stay up to date on something, so 20 minutes a day is fine, but you don't want to fall into the trap of killing 3 hours on there. So, you could make it full speed for 20 minutes of daily usage, then gradually degrading from there. By the time the speed degrades, you've probably done all the truly appealing parts anyway and it's easier to walk away when nudged.
One goal is to quit something completely. For that, you probably want delay across the board so that it eventually saps the joy out of the experience.
Another goal is practicing moderation. With social media as an example, maybe you want to stay up to date on something, so 20 minutes a day is fine, but you don't want to fall into the trap of killing 3 hours on there. So, you could make it full speed for 20 minutes of daily usage, then gradually degrading from there. By the time the speed degrades, you've probably done all the truly appealing parts anyway and it's easier to walk away when nudged.
or tie every login to a donation to the other political party. that should do the trick.
I’ve seen this used to good effect with coworkers that habitually ask for help before trying to solve the problem themselves. Instead of ignoring them or complaining that they’re wasting your time, wait to respond for a few minutes so that you’re no longer faster than looking the information up for themselves.
Obviously this only works over some kind of messaging service; face-to-face conversations have significantly different expectations around long pauses.
Obviously this only works over some kind of messaging service; face-to-face conversations have significantly different expectations around long pauses.
I often just ask my coworkers to give me a minute to finish the detail aim working on at the moment. I don’t think it is rude to let them wait a minute or even five when they come and interrupt my flow.
I try and do this with customers, if I slow the response they often figure things out for themselves.
This is what I do with my kids.
They both have the habit of very frequently interrupting me to ask me questions they either know or can find the answer to easily, or asking me to do things they can do for themselves.
I try to avoid just giving a blunt "no" because I'm also trying to instill in them the idea that family is about helping each other. So I try to say, "Yes, but I'm in the middle of ___. Give me a few minutes then I'll help you."
More often than not, as if by magic, it turns out they have the capacity to do it themselves all of a sudden.
They both have the habit of very frequently interrupting me to ask me questions they either know or can find the answer to easily, or asking me to do things they can do for themselves.
I try to avoid just giving a blunt "no" because I'm also trying to instill in them the idea that family is about helping each other. So I try to say, "Yes, but I'm in the middle of ___. Give me a few minutes then I'll help you."
More often than not, as if by magic, it turns out they have the capacity to do it themselves all of a sudden.
I really like this idea of a Chrome extension that makes every load on Twitter/Facebook/Hacker News/[your vice goes here] just take something like 0.5s longer. If no one else builds this, I think I will at some point.
My data plan goes to 3g (feels like 2g) speeds when my data runs out. Its actually awesome, I still get email etc, but browsing crappy content becomes really slow so I avoid it. I wish you could buy cheap 3g only plans
I don't know if that's why, but HN is usually way faster than the linked sites, and I more often than not end up browsing the comments instead of the intended content.
This is one of my favorite blog posts of all time. It's applicable not only to just work work but a lot of other things, if you can shorten the feedback loop, you get a much better chance to improve the end result. It affects _everything_ else too.
You make a good point. How do you compare your idea to the one that we need to take time to smell the rose? I think that idea suggests that we need to slow down and watch the world more closely. Just wanted to know what you think of that.
That's a great question! If I'm understanding it right, I think the two ideas can complement each other. For broader goals or when you're totally clear what you want to do and how you get there, it's fine to take time. Even then, you can use shorter feedback loops to make the process more efficient.
Say you want to become a better writer. That's a broad goal and there are several approaches you could take towards that goal. On one extreme, you could read a lot about writing, write little, try to perfect things, and get something out once or twice a month. On the other extreme, you may write every single day and get it out in front of some people, get consistent feedback, learn, and improve. Both of these approaches will take time… the second approach, with the shorter feedback loop, can probably get you there faster though.
Say you want to become a better writer. That's a broad goal and there are several approaches you could take towards that goal. On one extreme, you could read a lot about writing, write little, try to perfect things, and get something out once or twice a month. On the other extreme, you may write every single day and get it out in front of some people, get consistent feedback, learn, and improve. Both of these approaches will take time… the second approach, with the shorter feedback loop, can probably get you there faster though.
Thank you for your thoughtful answer.
A counterintuitive thing I've discovered us that working fast let's you solve more complex problems. At first it seems that you should try to go slow to make sure that all the cases are properly treated. Proceeding this way can result in nearly endless refinements as you go and losing sight of the main goals from time to time and repeatedly forgetting exactly where you are in the grand plan and which direction/step you were headed.
Going fast doesn't allow for secondary concerns and produces a single simple solution. Of course you can now do everything else it needs that you think of but code written this way with a clear core path is so refreshing from bottom-up generation where every detail has equal importance.
I even recall a time where I was performing a cascade of rebases and merges across three git branches and 4 or more submodule branches. Each feature update/sync took so many tries to get right. I eventually got fed up and just brute-powered through it without prethinking it. Because it was a short time from start to finish I was able to clearly see each commit in each tree I was working on without a pause wondering where I was or doing next. It was also less error prone than going slow. It fact I just did the whole process twice in a fraction of the careful time and compared results. No diffs were taken as correct and any diffs were examined and the correct variant used.
Going fast doesn't allow for secondary concerns and produces a single simple solution. Of course you can now do everything else it needs that you think of but code written this way with a clear core path is so refreshing from bottom-up generation where every detail has equal importance.
I even recall a time where I was performing a cascade of rebases and merges across three git branches and 4 or more submodule branches. Each feature update/sync took so many tries to get right. I eventually got fed up and just brute-powered through it without prethinking it. Because it was a short time from start to finish I was able to clearly see each commit in each tree I was working on without a pause wondering where I was or doing next. It was also less error prone than going slow. It fact I just did the whole process twice in a fraction of the careful time and compared results. No diffs were taken as correct and any diffs were examined and the correct variant used.
Going fast doesn't allow for secondary concerns and produces a single simple solution.
That doesn't sound like going fast, so much as "the simplest thing that could possibly work." Once you have that running, you can see where the shortcomings are and start to fix those. That will often proceed faster than trying to envision the whole complex thing up-front. (And that often results in a complete, but illusory vision, which ignores something which only becomes apparent once it's realized.)
That doesn't sound like going fast, so much as "the simplest thing that could possibly work." Once you have that running, you can see where the shortcomings are and start to fix those. That will often proceed faster than trying to envision the whole complex thing up-front. (And that often results in a complete, but illusory vision, which ignores something which only becomes apparent once it's realized.)
This is absolutely true. I'll usually have mulled over a problem for a long time before writing any code so have a sense of some of those other areas and have imagined mechanisms to handle some things. When it comes time to implementation, going fast focuses on the key ones.
Actually this is great advice, I should do it more. I already found it was great writing essays back in school - instead of painfully trying to be perfect, just knocking something out becomes a first draft. Same with getting kids to tidy the room, making it a fun race instead of slowly considering each piece gets chores done more quickly.
Work fast, don't think things through, make mistakes, pay for your haste by spending more time fixing your mistakes than you would have had you thought things through.
You can definitely go the other way to overthink a problem, even as high to induce the halting problem. Absolute optimization is mathematically impossible, and an imperfect choice has to be made at some point.
Measure once, cut twice, earn one to throw away.
This is a bad analogy for software. One of the unique properties of software, compared to other crafts, is that the material cost of iteration is virtually zero. We should use that to our advantage instead of pretending we're carpenters.
Often fixing fucked up shit takes more time than doing it from scratch but because of the system has been built around the fucked up shit you can't just throw it away and then you end up having to deal with continuously paying the higher than should price.
In software the material cost is not the cost of a concrete material such as wood (like you mentioned) but developer time
In software the material cost is not the cost of a concrete material such as wood (like you mentioned) but developer time
Even using the carpentry analogy, I suspect the point is to avoid ruining something on which a lot of time was spent. The material cost of most raw materials isn't very high, but ruining something you've already spent hours crafting is extremely costly.
The other thing to bear in mind is that there is always more work to be done than time to do it. You have to factor in opportunity cost. As many other commenters have said, ultimately it's a balance which depends on your company's particular situation.
The other thing to bear in mind is that there is always more work to be done than time to do it. You have to factor in opportunity cost. As many other commenters have said, ultimately it's a balance which depends on your company's particular situation.
> The material cost of most raw materials isn't very high, but ruining something you've already spent hours crafting is extremely costly.
Thanks to version-control software it's also incredibly cheap to experiment freely with an existing code-base in a completely non-destructive fashion. I see no reason to treat existing code as fragile or precious.
Thanks to version-control software it's also incredibly cheap to experiment freely with an existing code-base in a completely non-destructive fashion. I see no reason to treat existing code as fragile or precious.
Sounds nice on paper. Reality is, you figure things as you go along. Plan for 6 months, and you will see you have 6 months of work.... Get to action first, and you'll have maube 6, maybe 7... Anyways...
Not ideal, but mistakes and experiments seem to be the best way people learn.
There's nothing wrong with making mistakes in experiments. However, when you're building financial systems, there's absolutely no room for mistakes.
Most financial systems are designed to have room for mistakes.
Banks keep ledgers of transactions instead of just the balances, so that if an account balance is off, it can be recalculated from the transactions.
Transactions can be cancelled in case there was an error.
Invoices are often checked by humans before they are sent to customers, introducing an option to catch errors. If the customer receives a faulty invoice, they can contact whoever wrote it and ask for a correction. And so on.
Of course, there isn't room for error in every corner -- having a flaw in an authentication or authorization protocol could be very costly to recover from.
But in general, the assumption that in finance in general, there is no room for mistakes is simply false.
Banks keep ledgers of transactions instead of just the balances, so that if an account balance is off, it can be recalculated from the transactions.
Transactions can be cancelled in case there was an error.
Invoices are often checked by humans before they are sent to customers, introducing an option to catch errors. If the customer receives a faulty invoice, they can contact whoever wrote it and ask for a correction. And so on.
Of course, there isn't room for error in every corner -- having a flaw in an authentication or authorization protocol could be very costly to recover from.
But in general, the assumption that in finance in general, there is no room for mistakes is simply false.
There is always room for mistakes if you start by building prototypes. In fact having first approximation prototypes allows one to catch mistakes in how systems and subsystems interact early and fix those at a fraction of the cost.
Developing on a live fintech system is a different kettle of fish
Developing on a live fintech system is a different kettle of fish
> However, when you're building financial systems, there's absolutely no room for mistakes
Then I can assume that all of your financial software has verification proofs and/or is fully model checked? If not, then clearly there is room for mistakes even in finance.
Then I can assume that all of your financial software has verification proofs and/or is fully model checked? If not, then clearly there is room for mistakes even in finance.
[deleted]
> But it does mean, push yourself to go faster than you think is healthy
I really disagree with this. Aiming for something you actually think is unhealthy means you either think you should be working unhealthily ( :( ) or you don't trust your measure of healthy (in which case recalibrate that).
I really disagree with this. Aiming for something you actually think is unhealthy means you either think you should be working unhealthily ( :( ) or you don't trust your measure of healthy (in which case recalibrate that).
I wouldn't read too much into the word choice there. "Uncomfortable" is probably a better way to say it.
Speed derived from managing scope is the real value IMO. It's not about working faster, but rather minimizing scope constantly to ship faster and collect feedback.
Discussed at the time: https://news.ycombinator.com/item?id=10020827
My view is that all programmers produce roughly the same amount of bugs per hour, it is just the bugs per feature which differ. Of course bad programmers can spend a lot of time fixing bugs as they go making the end result have few bugs, but still the main time-sink is fixing all of those bugs.
So to become fast, learn to write code which is very easy to verify that it works. If you get surprised when things work the first time you try then you are not fast.
So to become fast, learn to write code which is very easy to verify that it works. If you get surprised when things work the first time you try then you are not fast.
Meanwhile there are martial arts and other physical disciplines where you go slowly to make sure you train the muscles along the entire movement instead of going in jerks and starts (which is how you damage yourself).
Fast iteration isn't about doing things faster. It's about requesting feedback more frequently. Which often means doing less, not more, and then evaluating the effectiveness of that small amount of work. Then adjusting your plans.
In writing, doing an entire book before your editor can tell you you're accidentally stealing a storyline from another author is bad. His analogies seem to be equating to this sort of behavior but missing the cause.
Fast iteration isn't about doing things faster. It's about requesting feedback more frequently. Which often means doing less, not more, and then evaluating the effectiveness of that small amount of work. Then adjusting your plans.
In writing, doing an entire book before your editor can tell you you're accidentally stealing a storyline from another author is bad. His analogies seem to be equating to this sort of behavior but missing the cause.
Oh please. Our whole product is a side effect of "working quickly", and it's anyone's guess how difficult it is to make any change in that now.
I have a different experience. I did lots of well thought work, that after management decision ended in the thrash. I prefer “working quickly” now, if it doesn’t end in the thrash, I can fix it later.
Yeah the farther I have gotten in my career, the more I ascribe to a disposable code philosophy. Of course it doesn't mean that it's a balance, and there's a time and a place for structure and thinking about design, but that is almost always done better when you have a working prototype than when you're starting something from scratch.
If your code doesn't kinda suck, you're putting too much effort into the code and not enough effort into the problem. It's weird, but important to learn.
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails
And I thought they wanted argue for faster replies...
But I think there is some truth to that. If a task seems overwhelming, it can sometimes help to look back at something you already completed.
I don't have that impression for programming at work, since I have a set schedule anyway, but for projects outside of that the kick-off seems to be the hardest part in awe of all the work before you. But then there is all the projects you already completed, which were mostly labor intensive as well.
And I thought they wanted argue for faster replies...
But I think there is some truth to that. If a task seems overwhelming, it can sometimes help to look back at something you already completed.
I don't have that impression for programming at work, since I have a set schedule anyway, but for projects outside of that the kick-off seems to be the hardest part in awe of all the work before you. But then there is all the projects you already completed, which were mostly labor intensive as well.
I think timing is so important with communication. Even sending a message like "got it, I will get beck to you tonight" within a couple minutes makes you seem a lot more responsive than a more detailed message an hour later.
For anybody reading the comments here without reading the article, and assuming some toxic-management-friendly nudge to burn-out style working (as implied by some of the comments); it's actually a very useful and thought-provoking self-help essay that may help as a tool against procrastination.
"when you punch someone you need to pull your arm back, before you launch it forward. If you don’t your hit will be weak."
It's a cute way to think in opposites, but unfortunately as punching advice, it's untrue. Punch force comes from body mass x acceleration, not arm mass x acceleration.
It's a cute way to think in opposites, but unfortunately as punching advice, it's untrue. Punch force comes from body mass x acceleration, not arm mass x acceleration.
Did you mean to comment on this? https://news.ycombinator.com/item?id=20610839
Bruce Lee taught a martial arts technique that relied on not pulling back first - https://en.wikipedia.org/wiki/One-inch_punch
He pulled back, just not his arm but other muscles in his body.
[deleted]
The problem with punches is the reaction force. Better to not punch at all.
40 year old here. Speed doesn't matter as much as WHAT you deliver. First of all, people do not know how much time something takes. And secondly, they will forget how much time it took, but not how well it was made.
Responding fast to emails is just crazy. I lost count on how many urgent problems got resolved automatically. "Hey can you help me with this". 15 minutes later "Nevermind, found it".
I'm in the "Slow is smooth, smooth is fast" camp. https://www.lesswrong.com/posts/4FZfzqMtwQZES3eqN/slow-is-sm...
Responding fast to emails is just crazy. I lost count on how many urgent problems got resolved automatically. "Hey can you help me with this". 15 minutes later "Nevermind, found it".
I'm in the "Slow is smooth, smooth is fast" camp. https://www.lesswrong.com/posts/4FZfzqMtwQZES3eqN/slow-is-sm...
> And secondly, they will forget how much time it took, but not how well it was made.
Absolutely. Not saying speed is never an important metric, but virtually all complicated engineering and construction projects are difficult to schedule and exceed their time budgets. If the end result is worth it those birthing pains are quickly forgotten. But a poor output will never be forgotten.
Absolutely. Not saying speed is never an important metric, but virtually all complicated engineering and construction projects are difficult to schedule and exceed their time budgets. If the end result is worth it those birthing pains are quickly forgotten. But a poor output will never be forgotten.
Things do not exceed their time budgets,
they take as long as they take.
Time budgets are incorrectly predicted to be shorter so that, in advance, they appeal to profit oriented motivations.
> they take as long as they take
Sure, agreed, which is not to say that time budgets don't exist, and aren't exceeded :).
Sure, agreed, which is not to say that time budgets don't exist, and aren't exceeded :).
Another 40 year old here: I mostly agree and I've also found that thinking deeply about a problem for a long time before trying to build anything pays huge dividends. In particular I spend a long time thinking about how I can simplify the design to save implementation time, which means actually building it is faster. I also think a lot about UX and DX: simplifying installation, interface, maintenance, removing unnecessary knobs, choosing the right algorithms and tooling, etc.
I think waterfall style development works for one person inside one's own mind, but not beyond that.
A lot of the stuff I see from 20 year olds these days is monstrously over-engineered and Rube-goldberg like. Many keystrokes, sure, but less thought. This also yields bloatware that hogs resources and is hard to install and maintain.
http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer....
More thought and less typing young padawan.
I think waterfall style development works for one person inside one's own mind, but not beyond that.
A lot of the stuff I see from 20 year olds these days is monstrously over-engineered and Rube-goldberg like. Many keystrokes, sure, but less thought. This also yields bloatware that hogs resources and is hard to install and maintain.
http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer....
More thought and less typing young padawan.
Waterfall can work, and in all the businesses that build physical hardware it's kind of unavoidable. I've been a cog in a giant IC project and seen how it works there: architecture diagram at the top, broken into functional blocks, each individual contributor is handed a tight spec for what to produce with defined inputs and outputs.
But there are four big constraints on waterfall:
- it takes considerably longer
- it produces no visible results until right at the end
- all but the smallest changes require restarting the clock and budget
- it requires a small team at the start and a big one at the end (an observation dating back to Brooks)
But there are four big constraints on waterfall:
- it takes considerably longer
- it produces no visible results until right at the end
- all but the smallest changes require restarting the clock and budget
- it requires a small team at the start and a big one at the end (an observation dating back to Brooks)
36 yo here. I've found that it is incredibly easy to 'overthink' and therefore overengineer things, and I've seen a LOT of my coworkers fall into that trap. Analysis paralysis is real, and delivering something and then being able to iterate on it is a massive step in overcoming that. Way wayyyy too often I've seen people try to think of all the edge cases before starting work, and that's just not a viable approach to software development in today's world.
Also, disclaimer, I didnt actually read the article :o
Also, disclaimer, I didnt actually read the article :o
I agree... For personal projects, if I find myself overthinking something, it's time to just put together something that works.. that usually resolves a bulk of 'what if' questions that were freezing me up in the first place. However, it also means a decent amount of refactoring/or sometimes even junking what is tried out.
Trouble is that this approach rarely works beyond a very small team.
Trouble is that this approach rarely works beyond a very small team.
Age isn’t the most accurate proxy for experience. You can meet 30 year olds learning programming for the first time or 20 somethings with a decade of experience.
Speed doesn't matter as much as WHAT you deliver.
Seems to me, that the recent spate of online coding interview techniques are basically looking for people who type fast. I suspect that they're finding people who are actually "10X" coders, and people who have memorized the typing out of the solution.
(EDIT: A problem with such 3rd party companies, is that the incentives are subtly misaligned, as they are for any recruiter. If they can present a good image, and a steady stream of candidates who produce videos where they're going claka-claka-claka on the keyboard at a good clip, like a hollywood hacker (which runs and compiles) then they're golden. It doesn't matter to them, if they're missing out on good, thoughtful candidates. False negatives are the order of the day.)
Seems to me, that the recent spate of online coding interview techniques are basically looking for people who type fast. I suspect that they're finding people who are actually "10X" coders, and people who have memorized the typing out of the solution.
(EDIT: A problem with such 3rd party companies, is that the incentives are subtly misaligned, as they are for any recruiter. If they can present a good image, and a steady stream of candidates who produce videos where they're going claka-claka-claka on the keyboard at a good clip, like a hollywood hacker (which runs and compiles) then they're golden. It doesn't matter to them, if they're missing out on good, thoughtful candidates. False negatives are the order of the day.)
I think there are misalignments, but I'm not convinced that false negatives are one of them. If I can fill all my req's with amazingly talented, lovely and capable people, it doesn't really matter so much to me if there are other amazingly talented, lovely and capable people that get rejected unreasonably in the process (unless it starts to create reputational risk).
I think the bigger misalignment is the time horizons for success (placement vs successful performance), but that's something that'll get figured out as the interview companies build up their track records and keep track of how long their placements stay in their new jobs.
I think the bigger misalignment is the time horizons for success (placement vs successful performance), but that's something that'll get figured out as the interview companies build up their track records and keep track of how long their placements stay in their new jobs.
This post wasn't written for people who don't suffer from procrastination and perfectionism. As I sit here being anxious about what to work on next, holding onto tasks that aren't quite done YET, nothing could feel more like a breath of fresh air than this blog post.
This sounds like people who quote "slow in, fast out" in racing. Just like here it's not true. It's a "rule of thumb" for beginners. It has use in that context. The way to win a race is fast in, fast out, same with software.
edit: I'm 42, if the matters.
edit: I'm 42, if the matters.
I think there is a different connotation to "slow is smooth, smooth is fast", but agree it isn't really a great analogy for production, because it is about learning.
What they mean is that you can't be fast (on a track) without being smooth, and that typically beginner-to-intermediate drivers/riders are trying to be fast in ways that make them less smooth, and ultimately (and counter-intuitively) makes them slower. So the advice is to forget about being fast and concentrate on being smooth. The speed will come.
I do think this has value as an analogy for software, but it is in concentrating on your tooling and methodology - smoother operating will deliver real value faster than just trying to type fast.
What they mean is that you can't be fast (on a track) without being smooth, and that typically beginner-to-intermediate drivers/riders are trying to be fast in ways that make them less smooth, and ultimately (and counter-intuitively) makes them slower. So the advice is to forget about being fast and concentrate on being smooth. The speed will come.
I do think this has value as an analogy for software, but it is in concentrating on your tooling and methodology - smoother operating will deliver real value faster than just trying to type fast.
The point is not to be fast but to be correct. In racing, smooth is fast because you didn't mess up and run off line or crash.
In software smooth is fast because you didn't have to bug squash and refactor. But even if it isn't faster, the grandparent comments point was that it doesn't matter as much as being correct anyway.
In software smooth is fast because you didn't have to bug squash and refactor. But even if it isn't faster, the grandparent comments point was that it doesn't matter as much as being correct anyway.
The problem is momentum has two vectors, speed and direction.
Most problems in software engineering are caused by only optimizing for speed.
Most problems in software engineering are caused by only optimizing for speed.
Sure but is everything a race?
> "Slow is smooth, smooth is fast"
"A stitch in time saves nine."
"Haste makes waste."
Speed helps you deliver more.
Delivering something after it is needed is useless. Chronically delivering things the day after requirements change due to the world turning, is uselees.
Musicians and other technical performers practice both slow&carefully and quickly, so that over time they can be more correct and more quick (as quick as the task can appreciate)
> That doesn’t mean be sloppy. But it does mean, push yourself to go faster than you think is healthy. That’s because the task will come to cost less in your mind; it’ll have a lower activation energy. So you’ll do it more. And as you do it more (as long as you’re doing it deliberately), you’ll get better. Eventually you’ll be both fast and good.
"A stitch in time saves nine."
"Haste makes waste."
Speed helps you deliver more.
Delivering something after it is needed is useless. Chronically delivering things the day after requirements change due to the world turning, is uselees.
Musicians and other technical performers practice both slow&carefully and quickly, so that over time they can be more correct and more quick (as quick as the task can appreciate)
> That doesn’t mean be sloppy. But it does mean, push yourself to go faster than you think is healthy. That’s because the task will come to cost less in your mind; it’ll have a lower activation energy. So you’ll do it more. And as you do it more (as long as you’re doing it deliberately), you’ll get better. Eventually you’ll be both fast and good.
Haste != Speed.
Take the time now to do it as well as you know how to do; but you're also correct, and taking too long to do the thing is useless, as well as overbuilding.
Take the time now to do it as well as you know how to do; but you're also correct, and taking too long to do the thing is useless, as well as overbuilding.
> Speed helps you deliver more.
It might in the short run.
Take coding hacks for example. It is fast in the short term, but might cost you double in the long term.
Not saying that quick hacks can never have their place, but saying that being fast might cost you time in the long run.
So faster is not always faster, and does not always help you deliver more, depending on the timeframe.
It might in the short run.
Take coding hacks for example. It is fast in the short term, but might cost you double in the long term.
Not saying that quick hacks can never have their place, but saying that being fast might cost you time in the long run.
So faster is not always faster, and does not always help you deliver more, depending on the timeframe.
Joining my voice to the generation choir here.
Fully agree, including some of the sibling comments.
Fully agree, including some of the sibling comments.
28 year old here, I couldn't agree more.
Speed matters in other fields as well. I'm a former academic surgeon, now in semi private practice.
I would a always tell my residents that to start a medical practice, the 3 "A"s are important, and in this order. Availability, affabilty, and then ability.
People have a problem, and they want it taken care of. If you can be that guy, or company, that's there for them, then you'll get there business in the future, as long as you do a good job.
I would a always tell my residents that to start a medical practice, the 3 "A"s are important, and in this order. Availability, affabilty, and then ability.
People have a problem, and they want it taken care of. If you can be that guy, or company, that's there for them, then you'll get there business in the future, as long as you do a good job.
This post is so wrong headed and misguided that it borders on parody.
Some choice quotes from the post:
> It is a truism, too, in workplaces, that faster employees get assigned more work.
> Whereas the fast teammate—well, their time feels cheap, in the sense that you can give them something and know they’ll be available again soon.
> push yourself to go faster than you think is healthy.
Dude that’s not a feature. It’s a bug.
Some choice quotes from the post:
> It is a truism, too, in workplaces, that faster employees get assigned more work.
> Whereas the fast teammate—well, their time feels cheap, in the sense that you can give them something and know they’ll be available again soon.
> push yourself to go faster than you think is healthy.
Dude that’s not a feature. It’s a bug.
[deleted]
I always think together with do stuff faster, "do the simplest thing you possibly can" and "write less code" both allow you to develop, iterate and feedback faster overall. Without the other two you'll eventually hit the wall of too much complexity to keep going fast.
Delivering on time is good, having expectations set properly in the first place is better.
Working fast can be good, solving the right problem at any speed is better.
Personally I have not found my speed matters so much as my mental state. When all the things come together, I know what problem I'm solving, I know how to solve it, I have time to focus on it for many hours... That is when I can enter a state of flow and build a great head of steam productivity-wise.
Finally I think continued long-term attending to something can trump speed and overcome all kinds of obstacles that prevent progress at all let alone progress at some arbitrary sense of fast.
Working fast can be good, solving the right problem at any speed is better.
Personally I have not found my speed matters so much as my mental state. When all the things come together, I know what problem I'm solving, I know how to solve it, I have time to focus on it for many hours... That is when I can enter a state of flow and build a great head of steam productivity-wise.
Finally I think continued long-term attending to something can trump speed and overcome all kinds of obstacles that prevent progress at all let alone progress at some arbitrary sense of fast.
What is "speed"? What is "quickly"? What is "fast"?
As Carlin said, any person driving faster than you is a maniac. Anyone driving slower is a moron.
As Carlin said, any person driving faster than you is a maniac. Anyone driving slower is a moron.
I think we can all agree that we want to maximize the quality of our work, where quality is defined as how well our work satisfies our goal. Typically, the discussion is around speed vs. quality, but I think quality itself encompasses speed (time_to_market below):
quality = w_0 * time_to_market + w_1 * correctness + w_2 * performance + ...
The weights w_n vary across domains. As with most things, it's about finding the right balance.
quality = w_0 * time_to_market + w_1 * correctness + w_2 * performance + ...
The weights w_n vary across domains. As with most things, it's about finding the right balance.
Interesting post (esp loved the ending), but it missed two key points:
1) if you want less of something (e.g. email), you don't always have to say 'no', if that's a problem somehow you can also just deliver slowly
2) the best way to do things quickly is not to hurry, it's to break it into smaller pieces whenever possible, so that each piece is delivered quickly
When I was a teenager I realized a good puzzle that’s a metaphor for this trade-off. Can someone solve it and generalize it?
1. Suppose you want to draw a line N pixels long. It costs X to draw a pixel, Y to copy and Z to paste. What is the cheapest (fastest) way to build the line as a function of N?
2. So I think in general, you may start slow, but them exponentially speed up, overtaking the spaghetti architecture guy.
1. Suppose you want to draw a line N pixels long. It costs X to draw a pixel, Y to copy and Z to paste. What is the cheapest (fastest) way to build the line as a function of N?
2. So I think in general, you may start slow, but them exponentially speed up, overtaking the spaghetti architecture guy.
Responding to emails quickly may make the other person happy, but it will create a mechanism that will interrupt you regularly. Peter Drucker - an author who has written many books about management - says that you need large amounts of uninterrupted time to get work done.
Mind a situation and consequences.
Working quickly helps you validate your idea fast and iterate.
Working quickly can also mean not putting enough thoughts into planning and researching, so you just waste your money, your time, or your credibility faster.
Working quickly can get you promoted.
It can also ruin your health and personal life.
Working quickly helps you validate your idea fast and iterate.
Working quickly can also mean not putting enough thoughts into planning and researching, so you just waste your money, your time, or your credibility faster.
Working quickly can get you promoted.
It can also ruin your health and personal life.
In the context of startups, speed definitely does matter. Reminds me of something PG used to say at YC - "if at some point you don't feel ashamed of what you released, then you released it too late" (paraphrasing).
Ugh. Agree with caveats: I’m often put in the position of being the “slow” guy because I have to fix all the stuff the “fast” guy did, but I have to do it while everything is up and running with paying users.
Now I just need to know how to become fast. The article did not tell.
Crazy, the power law exists even in speed
That's why the thing about "premature optimisation is the root of all evil" is mistaken and wrong in these modern times and yet many people still quote it and take it to heart and as a result don't prioritise speed when building software.
"premature optimisation is the root of all evil" is a saying that came from 1974 when computers were slower, languages were less effective and development processes immature. Today you should make your software fast.
"premature optimisation is the root of all evil" is a saying that came from 1974 when computers were slower, languages were less effective and development processes immature. Today you should make your software fast.
Premature optimization is as much a problem today as it was in 1974.
When you build a framework to support a feature you decide to never implement, that's premature optimization.
I'm not concerned with optimizing code, generally. I'm concerned with optimizing developers. Don't waste time on unnecessary work.
When you build a framework to support a feature you decide to never implement, that's premature optimization.
I'm not concerned with optimizing code, generally. I'm concerned with optimizing developers. Don't waste time on unnecessary work.
Optimization is an easy trap to step in. You can take it up in other layers aswell, optimizing your choices about the choices to optimize | Ad infinitum.
At some undefined point you may realize that you are trying to solve an undecideable problem. You can spend an infinite amount of time, and not get an answer.
You cannot build an algorithm to determine the amount of time that an arbitrary problem can be solved in, or if it's solvable in the first place. You must make a choice based on imperfect knowledge.
At some undefined point you may realize that you are trying to solve an undecideable problem. You can spend an infinite amount of time, and not get an answer.
You cannot build an algorithm to determine the amount of time that an arbitrary problem can be solved in, or if it's solvable in the first place. You must make a choice based on imperfect knowledge.
You didn’t read the post, did you?
Wouldn't modern times make it more relevant ? I would choose "don't worry about speed, make it happen first".
No I think speed is a primary feature, not a secondary one. As the article says, users relate completely differently to a responsive application.
The point remains that modern hardware is already super fast. Besides, avoiding "premature optimization" is to avoid efforts to speed up parts of your code which were never a bottleneck. No one is arguing for writing slow code.
I love this presentation because it adds strong economic arguments to a lot of practices that are quite common in software engineering but typically lack good argumentation as to why they are good. He covers a lot more ground in this presentation. Well worth your time if you are involved in any way in planning software development. I love his notions of option value and cost of delay. Cost of delay is exactly the economic argument why working quickly is important. Once you get it, is obvious that you should do agile, release early, and avoid embarking on long/uncertain refactoring/redesign efforts unless you can justify the payoff.
In short, any development that ships early maximizes the useful economic life on the market. If you ship something new earlier than your competitors, you get to charge a premium until they catch up. At some point your new thing becomes a commonality and the value drops. In some case, OSS just gobbles it up and the value becomes 0$.
So shipping 3 months earlier means you get to earn revenue for 3 months extra when it is still most lucrative. If you instead delay for 3 months because you are doing some thing that make things better in some way, you have to consider the cost of doing that AND the cost of missing out on that early revenue.
Don Reinertsen suggests you simply do the math consider the cost of delay when e.g. deciding on a big refactor vs. a lets get this to market ASAP type strategy. You don't even have to do a particularly good job at doing the math to out-compete gut feelings here.