As a further point to this, I found myself in a trap with work for 2 to 4 years where I would often spend ages mucking around before actually starting it. Becau

As a further point to this, I found myself in a trap with work for 2 to 4 years where I would often spend ages mucking around before actually starting it. Because I was worrying I'd get it wrong/not be able to do it/not sure where to start. Perfection desire, whatever. Another great time waster was refactoring parts of the system (which I still do today, but a lot more strategically). If a project is 4 weeks long I'd spend 3 weeks basically pissing around and then 1 week blitzing it. I mainly got away with it because I was smart and fast, but got in trouble sometimes when they'd be a surprise "show us where you are". Somewhat ironically, the best thing to cure this is to make a bunch of stuff. Make a prototype as fast you can. Make the prototype outside the existing system if it's complex. This especially holds true for things in web programming where a lot of things can mesh together as well as you needing to make an input form in HTML that might need to be complex and then suddenly you're dealing with how you'd make X complex control in javascript and dynamically load Y from the database. Ignore that complexity for now. An example is if you need to make an integration with an API, muck around with the API in an isolated console app first. Hardcode the input params, don't even bother accepting arguments. Manually change them and re-run to test different inputs. Roughly map out the API, then cut and paste the bits you want to keep, rewrite the bits you don't. If you're a junior and don't know how to make stand-alone apps, learn, it's easy (you'd be surprised how often I've come across this, junior web devs only knowing how to write something in ASP.Net but not knowing how to make a simple console app). Another trick when I'm really prevaricating or avoiding some particularly nasty or boring code is to write the code in comments. Delete each comment as you've replaced it with real code. It's usually enough to get me started. I even often write just a few comments and then because the design's finally clicked in my brain start writing the actual code in impatience to get it done. //set the start date to start of day //set the end date to the end of that day //foreach thing // parse the param // validate param //etc. Naming can also be hard, if that's getting you stuck, call the method "DoThing" and write it, then you'll usually know what to call it by describing what it does. Or focus on getting one bit done. If it's a report, I always write the SQL standalone first, use a bunch of hard-coded params at the top of the statement that I can comment out when I copy it into the method and start parameterizing the query. Then I write all the scaffolding around it. If it's something that's got complex back and front-end code, I get one bit of it roughly working before the other (usually the front end with a dummy object), I don't attempt both at the same time. TLDR; Stuck? Break it down in to chunks and tackle the smallest thing you can to get you started.