#1 It’s the communication, stupid!

Even if you’re a solitaire, ‘I-can-do-it-all-by-myself-and-know-how-to-do-it-so-stop-telling-me-how-to’ kind of person – you can’t and shouldn’t ever assume that the other person, no matter of his/her experience, technical background or expertise:

• understands the assumptions  that have not been precisely defined/determined excactly the same way as you do
• puts the same importance on them as you do

In other words – ‘good enough’ might be a completely different animal in your world, than in theirs. Same goes for ‘urgent’, ‘soon’, ‘almost there’, ‘small problem’, ‘a bit more time’

Define. Confirm. Leave no room for doubt.
Don’t delay to say you’re behind schedule. Don’t be afraid to say there are unknowns that cause issues. Keep everyone involved in the loop.

#2 Learn to plan & estimate for the unexpected, don’t underestimate the unexpected

No matter how experienced you are, be aware, that your knowledge at the time of estimating might not reflect the final/expected feature scope/result in 100%.
Communicate this (as stated above). Perform a reasonable research to minimize/eliminate  the unknowns.
Once complete – break down and write down high level tasks, either on paper/whiteboard or using your favorite task management / to-do list  (i.e. Wunderlist, Any.do, Remember The Milk etc.) or mind-mapping tool. (Mindjet, MindNode, Freemind, Coogle etc.)
This is for a high-level overview, so it’s not the same as having all required tasks entered into Jira/Redmine/Basecamp.

#3 Third time’s a charm. Learn from your mistakes, don’t repeat them

Everybody makes mistakes. No, really, EVERYBODY. This guy. This one. This one too.

http://spectrum.ieee.org/tech-talk/at-work/test-and-measurement/columbuss-geographical-miscalculations

Good news for you – you’re not a celebrity, you’re mistakes are highly unlikely to be noticed by anyone but your closest peers.

But failing to learn from them will cost you in a long term. If you’ve caused some serious mishap with Git merges simply because you hardly knew what you were doing – spend the next evening or two on learning and understanding how it works so that you don’t repeat the same error again and again. Same goes for every other tool/technology. If you need someone to explain it to you – ask.
Don’t be ‘this guy messes it up every single time‘ kind of person.

#4 Be trustworthy. Underpromise and overdeliver. Never the other way round.

Don’t be a yes-man who agrees on everything just to please the client / product owner / team leader, only to fail miserably in keeping his promises when the deadline hits the calendar. Let this happen a number of times and you’ll earn a reputation of untrustworthy and unreliable person who never delivers on time/quality/scope – something you want to avoid at almost any cost, as reputation is one of the critical factors to build your career upon, especially if you’re  planning to change your work environment, but not dramatically (i.e. switch jobs, but not moving to another city/country).
Keep in mind that word of mouth is a double-edged sword.

#5 Constantly improve to be proud of the quality of the things you develop.

Which might be a bit hard if you’ve on the very beginning your career path. But no matter how small or irrelevant the tasks may appear – do your best to achieve high quality. This doesn’t mean goldplating, or adding ‘just one extra feature that’s so nice’ – rather developing/designing in a way that you know isn’t subpar, in a way that’s up to (or above) general standards.
Resist taking quick shortcuts – chances are you (or someone else) will need come back to the code one day.
If there are situations that urgently  require quick&dirty solution – plan (and announce it) and schedule refactoring the solution later on.

#6 Find a mentor. Be grateful. Pay it forward

Chances are you’re working (remotely, or on site) with a team of other, likely more experienced, developers, designers, product/project managers. If there’s at least one person with significant knowledge/experience willing to share it – great, this could be your mentor!

Learn from them, listen to what they say, ask relevant questions. Don’t treat them as if they are your personal search engine, even they can come up with working solutions faster that you’ll ever be able to enter another search query. Rather – arrange a daily coffee/lunch break talk scheme, during which you’ll raise your questions, doubts, ask them to explain to you why&how’s of their tasks.

This will be a great and invaluable addition to your daily Stackoverflow/HackerNews routines.
Once you start gaining real experience, proven by all the completed projects – don’t keep it for yourself. Share.

Now that you know what’s important – none of the above sounds particularly difficult or unmanageable, doesn’t it? If so, why not start implementing them today, one by one.

Or if you have other ideas – please share them in the comments sections below!