What Does It Take To Be A Developer (Other Than Coding)?

What Does It Take To Be A Developer (Other Than Coding)?
To sign up for our daily newsletter covering the latest news, hacks and reviews, head HERE. For a running feed of all our stories, follow us on Twitter HERE. Or you can bookmark the Lifehacker Australia homepage to visit whenever you need a fix.

Coding is the biggest focus for most aspiring developers, but the truth is it takes a lot more to be a professional in the field. So we want to know: what else does it take to be a professional developer?

Photo by Jon Lim

There are a lot of skills that newly-qualified developers go into the field not knowing. What are some skills an aspiring developer should build before landing a job, other than coding?


  • OK, i will give my opinion, i have been working professionally as a developer for 15 years now, i will combine points where i think is valid so this doesn’t end up as a wall of text.

    First thing, coding is a constant learning curve and will be …. forever, that’s hard to get your head around but its something you need to know if your looking at a long term career being a developer, obviously a core knowledge of programming structures will serve you well, no matter what you will always need to learn a lot of new things year in year out.

    Secondly, Expectations and Time Management, the people you work for almost never understand how long things take in IT and will always ask for it to be done quicker, you need to take this into consideration and be firm on your estimates or else you will end up working til midnight, working weekends, working at home, the classic developer stereotype, you don’t want to do this and this just burns you out.

    Thirdly, Attention to detail, problem solving and logical thinking, your dealing with a computer, its built on logic, now while operating environments/integrated other programs may make it seem sometimes like they aren’t based on logic, but there is always a logical reason why something isn’t working, if you can train yourself to be more logical in your thought processes you can make your life a lot easier, this leads in to attention to detail, the smallest thing will cause you issues, check everything, pay attention to even the smallest thing, attention to detail is paramount, and both the above points help with your problem solving ability that you will use every day without fail.

    Finally, being a developer is not just a job, i have seen and/or had very talented developers working under me who have quit and moved into other careers (i consider it the five year wall, as it almost never happens with anyone in the industry over the five year mark), it can be very demanding due to the points i have covered above, you really need to have a keen interest in the area to make a long term career from development.

    I regularly used to be asked “should my son/daughter become a computer programmer, i hear its good money?” and my advice always was and always will be “if they have no personal interest in being a developer apart from the money, they won’t last in the career”

    I would say for those that are interested, do courses, see if it still grabs you after doing it a while, a lot of people very quickly realise that this is not something they can see themselves doing day in/day out.

  • Be prepared to have the finger pointed at you every time there is a problem.. I work in industrial automation ( Coding to run automated production lines basically ) and every time there is a problem wether it be Mechanical , Electrical or coding the blame instantly gets put on me because im there and on a computer.

    People find it very easy to blame the computers for their problems without any evidence and all because they dont really understand what it is I do. It’s quite often up to me to prove to these managers that what I am currently doing is no affecting them. It makes it very hard because they aren’t computer savvy.

    • I feel for you. Looks like you’re wearing the fall out of the myth that management can be independent of content; so you’ve got managers who don’t know what does or must happen, or even how it happens…and the company thinks they manage??

      • These managers are very good at managing the process and their workers.. When it comes to faults they lose their head because they are pushed so hard for results.

        For example. Mars petfood make their managers acount for downtime of every line to the second and what was the cause.. They just love to write my name next to it because it effectively means they dont have to prove anything and everyone agrees it was a software issue

    • This. SO MUCH THIS. I’m a software (and some hardware) developer for a small Winery Automation company, and, especially during vintage (busy time for wineries), I am basically an IT support guy for issues on-site that are completely unrelated to us.

      If something doesn’t work, before checking the things they think they understand, they’ll point to the thing they don’t even pretend to.

      • Yep I can empathise.
        I am constantly doing the work of the companies general I.T staff because there are none on site, which is mind boggling for places that are run by computers.

        Quite often I will be fixing a sites network and pc hardware issues to solve problems they think are related to our software.

        I just take it as part of the job and enjoy the challenges I am faced with day in day out.

  • Learning how to work management. Often you will be placed in a position to advise how projects should proceed to management who often don’t know code at all. This means learning how to explain things with simple terms, and learning how to convince people (make sure you are correct before doing so) who don’t know your field well, that what you propose is correct. At the end of the day your architectural decisions all the way to your implementation, and all headaches that the aforementioned create will be dumped solely on you.

    Don’t expect the person in charge to take any credit for any problems, only success’s. This also trickles down to learning how to work with and convey your decisions to anyone who works under you. You need to be a master of people skills and (as evil as it sounds) in some cases manipulation. For the sake of you own personal well being, and the well being of the product.

  • Problem solving skills!
    You will not have always the right answer and google or stackoverflow doesn’t know everything so you have to get the most from what you know

    • This is almost the #1 skill needed for developing (not to mention a range of other jobs). You need to be able to break a problem down into it’s parts, and know where and how to find answers when you get stuck.

    • It will never have the right answer if you don’t have the right questions. That’s probably one of the biggest things – learning how to use the resources you do have and apply the thinking and solutions from similar past encounters to the current problem.

  • Communication is the key ingredient. You need to clearly communicate with:
    – customers/end users/project managers: to be able to understand and translate what they want/need into some form of application.
    – other developers: when a project workload is broken up between developers, you need to communicate with the others to synchronize how the components will work together, when pieces will be complete. Your code is also another form of communication with other developers (as well as yourself).
    Creativity: you are willing into existence a creation either by your own design or a client’s. There are many applications that do the same thing (shopping cart websites, calculator programs, tetris clones) but they are all have something unique about them. There are also many approaches to the same problem: don’t always assume that one solution is always better than another. There is usually always a tradeoff.
    Flexibility: Never assume mastery – implies total knowledge – does this mean that there is no more to learn?. Keep up to date with developments in technology. Try to see the perspective of other developers and try to understand why an implementation is the way it is. Thinking outside the box may also allow you to solve bugs/issues that may not have been apparent from one perspective.
    Attention to detail, or curiosity? Finding out what makes things tick.
    Finishing: set a deadline/goal. Set small goals/milestones and then evaluate them. Work your way to completing a project/task.
    Time: there is so much to learn, but you also need the time to evaluate what you have accomplished and to grow.

  • A good grounding in:

    a. individual workflows, basically be as efficient as possible. For example take basic UI/UX web development, developer tools that can help you test, debug and automate as much as possible saving you time and hassle. More specifc? NPM, Yeoman, bower, grunt, gulp, browser timeline and dev tools, vagrant, docker, sass… and that’s just the tip of the iceberg (depending on what you’re coding of course).

    b. Version control (preferably distributed), something that’s essential to all projects where it’s necessary to work in a team. GIT is the easiest one to get your feet wet with and has plenty of documentation, tutorials as well as a huge userbase.

    c. Team workflows (Agile development concepts). I wont get into the nitty gritty of exactly what this is but the gist of it is (particularly if your working for a client) that requirements and outcomes are constantly evolving. The agile development cycle is designed to cater to and facilitate this process rather then creating set design parameters right at the start of what could potentially be a 2 year project (SCRUM is probably the easiest one to learn).

    d. Patience and understanding of how non-coders think. Once you get all this knowledge its almost like you have to unlearn what you have learned (in most cases) and put emphasis on flows and processes you find blaringly obvious. True alpha and beta tests are conducted for this reason but if you can do it from the beginning you’ll save time.

Show more comments

Comments are closed.

Log in to comment on this story!