6 ms·
Go Hard Early
"You’re not a teenager leaving your homework until the last minute. Professionals go hard early."
- deleted 14y ago[deleted]
- redguava 14y agoGreat advice. I always fall for the trap of expecting the last 20% to take 20% of the time. Not sure why I don't learn my lesson.
- khariel 14y agoSeems to tackle the Pareto principle: http://en.wikipedia.org/wiki/Pareto_principle http://en.wikipedia.org/wiki/Pareto_principle
- lifeisstillgood 14y agoYou aren't a teenager putting off homework till the last minute Such a common teenage response we all know it - yet it makes part of out formative years and so as professionals we need to unlearn our teenage years
- mootothemax 14y agoThis reminds me of an obvious-yet-not-that-obvious trick when it comes to quoting for new features using an unknown technology: Be honest, ask to sacrifice a couple of hours to throw at a proof-of-concept, and then you should have a better idea of how long the full feature will take to implement.
- praptak 14y agoIn my experience this applies to every feature. Doing a small chunk tends to improve estimates - somehow they tend to go up rather than down, go figure :-) This creates a sort of an impedance mismatch if you do your work in sprints - it's good to do the initial chunk in one sprint and the actual body of work in the next one. Unfortunately this means that features' implementation latency goes up.
- mootothemax 14y agoIn my experience this applies to every feature. Heh, I think it depends on the feature ;) Past the first few projects, you should have a pretty good feel for how long standard CRUD, user auth, email fun and other such things should take. Basically, the more experience you have, the fewer times you should need to sacrifice time for proof-of-concepts - but there'll always be a need for them :)
- praptak 14y agoWell yes, I meant "every feature" for some values of "every", obviously :-) For some features the gain is not noticeable enough to justify doing the initial spike.
- ultimoo 14y agoI winced at the last sentence -- "You’re not a teenager leaving your homework until the last minute. Professionals go hard early." I'm a graduate student who still leaves homework for the last moment sometimes. This mantra of going hard early can also be applied to a few of my assignments and academic projects.
- mahyarm 14y agoI think the entire psychological structure of academia leads to a tendency of procrastination. I don't procrastinate at work much at all, I procrastinated way too much in academia. Properly designed academia would probably remove procrastination from K to PhD.
- minimize_me 14y agoCan you elaborate a bit on said psychological structure?
- antninja 14y agoI'm not OP but presumably: homeworks are done alone at home whereas professional works are done within a team at a workplace. Procrastination is the demotivating consequence of working alone, isolated.
- ajanuary 14y agoTo add to the other response(s), there's a sense of artificialness to homework and the way it's drip fed. The deadline is just so the setter has a schedule to assess it, and the next one will be coming at some point in the future. With work it's usually all coming now. If you're not doing task a, you could be doing task b, c, d or e instead. Of course good planning and management will mean time is organised between all the tasks to get them done one at a time (or as close to) and it's not a daunting pressure, but I find there's always a sense that there's lots to do. In the cases I've had where there doesn't seem like a lot to do, that's when I tend to procrastinate with what I'm meant to be doing, looking at this and that other interesting thing we could be doing. [Edit] Also, money always helps ;)
- namank 14y agoWell, but there IS something to be said for letting the idea simmer. Isn't that where ideas come from?
- rubinelli 14y agoIn my experience, those parts aren't necessarily hard; they are hard to estimate, e.g. getting your interface pixel-perfect or interoperating with a legacy system.
- ajhit406 14y agoPerhaps more importantly, getting feedback early on your progress is incredibly important. These curves are all in 2 dimensional space, but you could very well be flying off into oblivion and not to your intended destination. Check in with mission control (customers / clients) regularly to make sure you're on the right path.
- k__ 14y agoGood idea for doing new stuff. If you do some stuff 1000 of people have done before, and hundrets of books are written about it, a good planing yields better results...
- banachtarski 14y agoThis applies on broader timescales as well. Get the hard problems out of the way not just on a project, but with the harder decisions in life too (what you're learning, what you invest in, what career to pursue, who to spend time with, etc).
- powatom 14y agoAll very interesting, but where's the evidence that this actually works? As they say - fail to prepare, prepare to fail.
- dancesdrunk 14y agoIt is decent advice but to be taken with a grain of salt - I've worked with developers who just dive in to the project, no plan in their head and just figuring out as they go along. What you're left with is a mess of code, hacks and workarounds - it works, definitely does, but maintaining or extending it is a nightmare. On the other hand you have projects with incredibly detailed architectures all mapped out, way too much time discussing / planning / envisioning what to build, when to build it and how best to go about it. Not a single one I can think of actually followed the plan (you will always get kinks in the road), and as such these things are always over due and over budget. I guess it's more about finding a balance with what works - perhaps keep an end goal in sight; with a simplistic high level overview of the project/feature, thus giving you the freedom to move around any problems that may arise, but also not tying you down to a detailed plan / architecture that almost certainly will need changing. Iterate fast, stay flexible(?) But one thing I definitely agree with - and that's to get started immediately; whether that's to plan or to code - just start. It will always take longer than you think, and that last 10% is equivalent to first 90%, if not more.
- bru 14y agoI think you're right, but I 100% reject this article. Maybe it is good advice for small- or middle-scale products, apps., etc., but it will never hold for a project whose goal is to make a global impact. I'm actually thinking about Fabrice Bellard, who was featured in a article that was met with success here two months ago[1]. > Bellard made it seem natural to pull together his mathematical insight, broad experience at instruction-level coding, and careful engineering to advance the field this way When you look at his achievements[2], I have trouble finding one that would have succeeded with OP's "advice". Between an app for coffee-lovers and QEMU, I think the careful thinking and engineering crushes the hype of "let's do it". Sure it sounds good, but that is not the way you will achieve something meaningful. I may sound like an ass while it is not my goal, but - I'm kind of surprised to see the success of this article (50 votes for 2 hours) given the low level and amount of content it offers - I distrust analogies, and this gamma-correction one is definitely unsound (not to say dumb) 1: https://news.ycombinator.com/item?id=5187585 https://news.ycombinator.com/item?id=5187585 2: http://bellard.org/ http://bellard.org/
- madiator 14y agoTry this in a coding interview and you will go home early.
- jared314 14y agoIt sounds like he just restated the idea of POCs and unknown-unknowns. You should consider yourself lucky if you have few enough tasks that you can "go hard early" on without destroying your work/life balance.
- T-zex 14y agoThe relevant concept is a Parkinson's law [1] Work expands so as to fill the time available for its completion. [1] http://en.wikipedia.org/wiki/Parkinsons_law http://en.wikipedia.org/wiki/Parkinsons_law
- whizzkid 14y agoAs much as I agree to what title says, i am against to what the context explains.
- rational_indian 14y agoThat's what she said?
- MortenK 14y agoOr you could apply proper, professional project management methods to make sure the last 20% doesn't take half the time of the entire project.
- ofacup 14y agojust because your spreadsheet says it will take this long, doesn't mean reality will take a lot longer
- MortenK 14y agoTrue at project start, but the further you progress the more realistic the estimates will be. Half-way through, you can do much, much better than being caught with a 20% effort turning into 50% effort situation. However, if you start by doing an off the cuff estimate and expect that to hold throughout the project, well yes, then reality will be very different. That's the situation where you end up with a 20% or even 10% estimated effort ballooning into a 50% or more effort. But as the author suggests, just getting into it and working hard from the beginning won't make a difference. That will just ensure a project-long crunch which will be highly detrimental to team performance.
- coldtea 14y agoYes, because those methods have worked wonders so far in IT projects, including multi-hundred million dollar ones...
- MortenK 14y agoIf you consistently have the "last 20% takes 50% of the project" situation, then your scheduling is based on wishful thinking rather than past performance. No method guarantees project success, as can be seen from plenty of failed high-profile projects. But basic project management and estimation methods applied not only at project start, will definitely get you out of the very basic problem of "90% complete, forever".
- 14y ago
- lsiebert 14y agoI think there is something to be said for not dithering over how to do it too much. It's a balance.
- lsiebert 14y agoI think there is something to be said for not dithering over how to do it too much. It's a balance.
- lsiebert 14y agoI think there is something to be said for not dithering over how to do it too much. It's a balance.
- perlgeek 14y agoIt's important to mention that "start now" doesn't mean "start coding now", but rather "start working now". Don't omit the planning phase.
- throwawayG9 14y agoThis is what I see: http://i.imm.io/12ieb.jpeg http://i.imm.io/12ieb.jpeg ...
- hunvreus 14y agoI don't think it is as much about "early" as it is about "intense and constrained batches of work". The "early" part of things is just a sound advice to avoid missing deadlines, but doesn't really help increase the quality of your work or reduce waste. Early discovery to outline a draft strategy in small committee (one person is sometimes enough) helps the team with reaching velocity quickly once it gets started. The hard part is sustaining it until delivery of whatever it is you've set up as the target. That's why sprints can be handy, reducing the amount that needs to be delivered so that the team doesn't get slowed down on a big block of work.
- scott_w 14y agoFrom the comments, a lot of people are taking the wrong message from this article. It's not "get stuck in and don't think about it", it's actually: "think about what needs to be done, then start with the hardest". It's actually something I learned during a group project during university. The process is something like: * Group all your main features * Plot them on a graph of importance (y-axis) vs difficulty (x-axis) * The features in the top-right (high importance/high difficulty) are the first things you do * The features in the bottom-right (low importance/high difficulty) are the last things you do This is something you have to keep evaluating over time, using a process/method of your preference (that works, of course). The reason you do the hard/important things first is because it lets you know whether the project can go ahead for the minimal cost. To take the group project I did as an example: we had to do a mapping application on a mobile device. Most groups went and wrote some code in Java, and wrote a routing algorithm. A few of us realised that getting something running on a device was the "hard" part, so set about getting that working. Afterwards, we went and drew some graphics, and handled some simple I/O with pre-programmed behaviour. When it came to writing the routing, we again tried everything against the device ASAP, so we knew what its real-world performance was. Those who started writing Java without the device realised they had to convert it to J2ME before they could make it run, wasting a bunch of time. A good percentage had nearly nothing running by the end of the year demo because of this.
- hexagonc 14y agoNo, this is not the message from the article. Perhaps, it is what the message should be, or what the author wanted it to be, but it is not what was said. Just reread the first sentences. I quote: You have a nice big project you’re about to get started on. Delivery is in a few months, so you have time to plan, sketch out some initial ideas, to let it germinate in your head. Right? No. Start now. He is saying that you don't plan. You don't have time to let it "germinate in your head". Don't look for the hard parts of the problem and tackle them first because, if the problem is nontrivial, you probably don't know what the hard parts are, anyway. The hard parts are the ones you don't expect from the start. The author's thesis is that you should start early so that you can encounter the hard parts as soon as possible. It is about the fact that you will encounter unexpected challenges that will force you to reassess your strategy. I'm not taking a stand one way or another. I think your strategy has its place (and in fact, is closer to the way I tend to do things) as well as the author's.
- columbo 14y agoThe problem I see is that this is really just your perspective of the project. It could very well be that the 0.5 gamma curve is really a hyperbolic sine (http://mathworld.wolfram.com/HyperbolicSine.html http://mathworld.wolfram.com/HyperbolicSine.html). If it is, are you going to have energy at the end to take that next mountain?
- lubujackson 14y agoThis only works if you are committed to trying out the idea and then JUNKING YOUR CRAP CODE. By the nature of coding problems, the bigger the codebase gets the worse bad decisions fester, so if you approach the early rounds as "trial and error time" and then commit to a big refactor once you DO plan out the bulk of the project, this can work. Otherwise it is easy to end up with a patchy mess.
- ivanjovanovic 14y agoI would explain this concept as two kinds of life philosophy and ways to approach the future. 1) "exponential" - which gets everybody happy at the beginning and then crushing them with hard reality after things start getting more and more complex. There are a lot of real life examples of doing this and I can rarely find the one which has brought the value at the end. In software development experience I have found this very wrong. 2) "logarithmic" - when you do a lot of investments into solving the hard structural/strategic problems at beginning and then riding much more far on the benefits they provide. This approach works pretty good in real life as well like investment into fundamental understanding, saving early so accumulated benefits get higher.