Tips to get a software engineer job

in #tech2 years ago

Your time is precious. Save as much of it as you can. Automate everything. Once your time is a commodity, you can achieve your next great innovation.

  • Use a powerful IDE (like VIM), and configure it to do as much as possible for you. Strive for single command Build/Test/Deploy/Run.

  • If you find yourself doing things frequently, make them happen with one button press, or click. Or better yet, make them happen automatically.

  • Ask questions until you can explain in complete detail to the next new developer that asks why.

  • Challenge the status quo by providing better alternative solutions - and make significant steps towards implementing them. If your tests are incomplete or run once a day/week, become the local Continuous Integration guru - pitch to your team the benefits and implement it. Once you are using it and it is helping you work better, get your team using it.

  • Don't just challenge others; challenge yourself. Never written a web app? Write one. Never done python? Hijack UAVs with python.

  • Own something. Create something. Doesn't have to be a technical project. It could be an event, like a meetup or a hackathon, a game, a website, or a blog.

  • Teach something. Java, public speaking, writing, chess, vim, tennis.

  • Be a beacon of excellence. Got a class/component that is rubbish? Fix it. Write code the right way. Don't take shortcuts in your code. Make intelligent decisions and justify the pros and cons why you made that decision to those around you. Continuously make improvements to your code. Spot a TODO that would take less than an hour? Just Do It.

  • Like your favorite language, browse the Stack Exchange in a topic you are familiar with. When you find something new to you, bottom out your knowledge of it as fast as possible. Know C? What's branch prediction? This post will tell you - to learn.

  • Browse the Stack Exchange on a topic you are unfamiliar with - every day's a school day.

  • Learn to communicate. Writing, presenting, problem-solving, intense projects, large teams, small teams.

  • Document everything you do as you go. You can refer back to why you did things and rely on your previous solution to similar problems when faced with them. It also helps capture your thought process and critical pieces of information you may forget. I frequently flick back through my diary over the previous few days' work.

  • Document your code before you've written it. Use system diagrams, class hierarchies, and flow charts to show how your code will work. If people have suggestions - and they will - you can make amendments more quickly than when you have written the code. This is the other biggie that I see surprisingly few people do, which can have the most harmful effects.

  • Be specific. So you've crafted your diagram for your new thing. Show it to everybody. Gather as much detail as possible. Ensure everybody agrees with the chart and change the diagram if they don't. If anybody puts a pen on your diagram, add those corrections to the diagram. Keep the diagram up to date.

  • Learn about unconscious bias and male privilege. Learn about MBTI, which personality type you are, and more importantly, how to interact best with other personality types. Learn about Emotional intelligence. Everybody in the world is different from you, and you need to know how to interact with them in the most efficient and constructive ways.

  • Regularly do something for your team. Bring in cookies. Teach a magic trick. Cultivate a bit of culture and encourage others to do the same. Only praise other people's contributions. A cohesive team is hard to beat.

  • Learn how to work with people. I personally really enjoyed The Pragmatic Programmer's "stone soup."

  • Understand and use other people's codes. If you are implementing your own XML parser, CSV reader, or GIT hook, you are Doing It Wrong.

  • Once you have written your code, and it works and passes your tests, go back and tidy it up. Re-run the tests. Now tidy it up some more. Classes should have a single responsibility. Functions should do one thing and be less than 20 lines long in most instances. Use self-documenting names for functions and variables. Spending time tidying up your code will be repaid 10-fold to you and the rest of your team.

  • Get involved. Take responsibility. If something isn't right, fix it. If the deadlines are slipping, suggest a solution and make others aware as soon as possible.

Look for software developer jobs that allow your mind to grow and beat itself every day!

Coin Marketplace

STEEM 0.17
TRX 0.15
JST 0.028
BTC 57856.68
ETH 2352.26
USDT 1.00
SBD 2.43