Comment by koonsolo
7 years ago
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...
> 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.
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 :).
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.
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)
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
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.
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.)
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.
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.
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.
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.
The problem is momentum has two vectors, speed and direction.
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.
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.
> 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.
Joining my voice to the generation choir here.
Fully agree, including some of the sibling comments.
28 year old here, I couldn't agree more.