Thoughts On How To Get Work Done

Published on . Takes about 3 minutes to read.

I have been working as a Software Developer for nearly exactly two years now. During that time I have learned a lot. Seriously, I used to write spaghetti code, but now I am all wrapped up in good architecture, continuous integration, separation of concerns and testing, to mention a few.

For the longest time I did what I do alone - but at long last there is some hope on the horizon. This post serves as a collection of knowledge / a list of guidelines to my future colleagues.

Be Proud Of Your Work

  • Produce quality. Your code should be well-crafted, conform to standards (whenever possible) and make you want to sigh happily once you commit it. Instantly attack any function that looks like a mess and make it better. Challenge yourself by asking whether what you just did could be done better.
  • Test your changes. Whether this means automated tests (PHPUnit) or even manual point-and-click - you should be testing your stuff. Claims like "works for me" leave you in a bad light and make you feel like crap later.
  • Accept constructive criticism. Code reviews are important. Be smart enough to accept / give out code review comments without taking it personally. Learn from experience.
  • Respect the client. Customers are our bread. Treat them respectfully, explain things, communicate on a timely fashion.

Play Well With Others

  • Document concisely. PHPDoc is your friend - write a short summary to all of your functions, classes, logic that is not immediately obvious. Keep in mind that the person reading your comments is a developer too - have some respect for their intelligence and do not waste time with needless lines of text.
  • Share ideas. Programming is a collaborative business. Pair program for an hour or two with a buddy (more, if possible). Debate over best approaches to a particular problem. Introduce new technology to team-members.
  • Do not break stuff. git commit -m "Broke the importer script". Why? Be reasonably sure your commits won't break the build. If they do, take responsibility and fix it.
  • Don't touch his code!  Be careful about "improving" work done by others - especially if it is not your project. Changing function foo_bar() to function fooBar() can result in a lot of bad air. Be willing to discuss why you changed something and only do it if your aim is to improve, not force something into your own patterns.
  • Commit often. Use version control. Seriously. Just do it. Every discrete change should have its own commit and a meaningful commit message (with a reference to the issue ID). Review the diff of other commits (code review).
  • Be ready to help. Accept pair programming invitations. Explain unfamiliar concepts without malice or judgement.

Keep The Ball Rolling

  • Keep learning. Developers learn something new as often as possible. Programmers just blunder along with their baggage of knowledge as long as possible. Browse hackernews / reddit / etc before / after work. Read technical blogs. Experiment with ideas and take risks.
  • Participate in community events. Garage48 is a pride to the Estonian startup community, Devclub brings together the best and brightest. Meet new people. Gain new experience. Learn new stuff.
  • Promote technical excellence. Put emphasis on doing something well over doing something cheap. Recognize good architecture and give credit where credit is due.
  • Refactor. Legacy code is nightmare-ish - and when do the clients ever pay for maintenance? Refactor and improve old systems whenever possible with baby steps. Optimize a long SQL query while working on something unrelated. Run "auto-format" when opening a spaghetti file.
  • Don't overspend. Sadly, you can not rebuild the entire system unless the customer agrees to pay. Do what is necessary and some more, but do keep it contained.

Be passionate about what you do and try to do it well. Work is not a job - and software developers have one of the best jobs on the planet.

Modern day software development comics