Comment by muse900 | Hacker News Reader

Comment by muse900 | Hacker News Reader

Practical work. No matter how many books you read, if you don't practice it you won't learn it.

Also a very important thing that I've learned over the years is that the difference that a Developer has and a Junior Developer is the confidence that he/she can succeed the task handed to them.

I personally as a developer, think that I can achieve anything you give me task wise, no matter the technology involved, I'll just learn it and do it. The time etc of course will vary and if you give me something hard that is out of my current profession it might take a lifetime to complete but my confidence that I will get it done is what makes me a developer (I believe).

Once you find the confidence to call yourself a developer then you'll be a developer.

Note: That leagues of developers vary a lot. I'd consider myself a very median developer, and I've seen others that are doing crazy things, that doesn't put me down. I am as valuable as they are, one person might be lacking a bit on maths but might have a better artistic side and the opposite. Generally over the years you will see people doing things that you think it would take you a lifetime to do but its just who they are. Don't lose confidence, your skills will be as important as the other people skills. Personally I combine an artistic side and as a median dev I can create nice mobile apps and websites and work both on the backend and frontend of things and thats helping small companies that employ me to get a kickstart. If I was to go to google, I'd prolly fail all the interviews and people there would be a lot better technically, but again they might not be able to bring the same skillset that I bring to those small companies. So by saying that I believe everyone is different and anyone can find a fitting place as a developer.

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.

Reply on news.ycombinator.com