Lextech News

Developer Roundtable (Part 1): Tips for students heading out into the workforce

August 23, 2013

  • Tom Caprel Tom Caprel

We set up a roundtable of Lextech engineers to talk about a number of subjects relating to coding, the workforce, and education. This week, we’re highlighting some tips they suggested for mobile developers just starting out in the workforce.

  1. Consistency is critical. If you are working on someone else’s code, follow the patterns they set and don’t just push your own styles, especially if that code will be touched in the future. On top of that, be flexible with your styles and behaviors. Everyone has different backgrounds!
  2. [pullquote style=”right”]”Systems-level thinking is a great asset for any developer to have…If someone told me this earlier in my career, I could’ve had a 5 year head start.”[/pullquote]

  3. Don’t reinvent the wheel. There are a lot of shared libraries, many of which contain several hundred hours of work. If you can get the right licensing, take advantage of what other people have already done.
  4. That being said, evaluate code you are hoping to reuse with a critical eye. There is a lot of garbage out there! If you are going to Google and search for an algorithm, make sure you are getting a good one. That is hard to do if you don’t know what to look for.
  5. Comment well, and name things descriptively so you know what they are when you come back. It sounds simple, but it makes a world of difference.
  6. Do a lot of research before you start on projects. Don’t jump in too fast; investigate first. Also, you should seek out best practices and emulate those as much as possible.
  7. Keep learning after you graduate from school or your skills will get stale! For example, one of the things that helped me with my Javascript was learning Ruby and Java. Exploring other languages helped me develop best practices.
  8. Find a mentor. That is something I wish I had early on to teach me proper conventions, help me find resources, and assist me out when I couldn’t sort out an issue.
  9. Learn source control and agile methodology. When I was in school, they didn’t teach me anything about it, and it makes a huge difference now that I’m out in the workforce.
  10. People get really myopic while focusing on the code, and don’t think about the living system their building. Systems-level thinking is a great asset for any developer to have, and the really valuable people in an organization understand the network, the middle layer, etc. If someone told me this earlier in my career, I could’ve had a 5 year head start.
  11. [pullquote style=”right”]”When you screw up (and you will) raise your hand and tell someone. You have to be willing to own up for the sake of making the project better.”[/pullquote]

  12. Don’t be afraid to ask questions and take initiative to try and figure things out. You’ll learn by solving problems yourself! Good problem solving is the most important skill you can have in software development.
  13. Refactoring is a wonderful thing. Regardless of how much design you have up front, priorities shift constantly. Code doesn’t pivot very well, so at some point you have to get rid of all the half-used code and stuff that doesn’t make sense anymore. Projects often live longer then you think they might, and maintaining the project is exponentially more difficult if it isn’t being cleaned up regularly.
  14. If you aren’t looking back at the code you’ve written in year’s past and thinking, “I could do that better today,” there’s a problem. Go back and look at your old code. It’s critical to helping you learn as a developer.
  15. Just because you can, doesn’t mean you should. There are many ways to do something, and just because you get a right answer doesn’t mean it’s the best, most efficient way to get that answer.
  16. When you screw up (and you will!) raise your hand and tell someone. One of the worst development problems is when you hear about an issue and someone says “Oh I knew about that 6 weeks ago!” and now it is blowing up your customer’s system. You have to be willing to own up to what you did wrong for the sake of making the project better, and everyone can learn from your mistakes.



We’ll be posting more insights from our engineers soon in Part 2!