I’ve been working with Deemaze Software for approximately 2 years now, and since my debut I have learnt more than I could have ever anticipated. It turns out, being a programmer isn’t just about coding. I know right, who would have thought?! There’s loads of management tips, tricks and nuances, business lingo, client expectations, internal and daily standups, quality assurance, code reviews, design specifications, alternating tight and lax schedules, cool and boring projects, etc. etc. It can be quite a handful! Thankfully, the team I work with has mastered the a̶r̶t̶ ̶o̶f̶ ̶w̶a̶r̶ art of juggling all of these concerns and taught me a great deal, so without further ado, here are some of the important lessons I’ve learnt throughout this incredible journey.
# Understand your role
I often find myself questioning client’s choices and decision, particularly those regarding what I’m supposed to implement and maybe maintain in the future. I’m no project manager, nor a client manager for that manner, I’m a developer, so most of the time I just have to give those people my perspective on the matter and let them handle the information as best they can. Unfortunately, I often couldn’t distance myself from the client’s whims if they end up disregarding my opinion, particularly if I can foresee trouble in the not so distant future. I have learnt to let go, or rather, I have been taught to let go. There is no use in stressing over what a client has decided after I have presented the pros and cons, it is their right and role to do so, not mine. This realization alone can lift tremendous proverbial weight from your shoulders.
# Failure is an option
No one’s perfect, that’s a no-brainer, and mistakes are inevitable, another super simple deduction, yes, but what often baffles people, myself included, is that every well managed project already accounts for you to screw up at some point (I know, crazy!). Now, this doesn’t mean you should actively strive to develop the quickest and most half-assed solution, only in hopes of justifying it as just another minor f*ck-up, far from it. It means you should invest enough time and effort into your job and solutions, even if they have some risk associated with them. And if they end up not panning out the way they were intended, as long as you gave it your best (and hopefully no one died), everything should be alright, and the world should continue just the same. Communication can play a very large role in this.
# Build what you’d enjoy using
It’s easy to dehumanize a project, especially when you have tight budgets and deadlines, already elbows deep in the project’s environment and task requirements, but it is equally important to take a moment to stop and criticize your work as if you were the end user, even if that is not your role. “This animation is wonky”, “this icon is not obvious”, “the instructions could be clearer”, “this [insert thing] doesn’t feel right”, these are all humble suggestions you should pass along and ask about, because chances are, you are not the only one thinking about them. Do bear in mind that there is no way of catering to everyone’s taste, and if your thoughts end up being discarded… well, we’ve already talked about understanding your role.
# Facilitate repetitive tasks
Be it time tracking or using your terminal, chances are that you have a couple of actions which you find yourself doing every day, sometimes multiples times per day. If you’re anything like me, the back of your mind is already screaming “There’s gotta be a better way!” instead of mindlessly memorizing and repeating complex tasks.
If you track your development time (and you should!), I recommend using a native app that boasts an offline mode instead of using a browser based application. I use toggle’s native app, as it provides me with an uncluttered browsing experience and doesn’t require an internet connection.
Sometimes I might be working on multiple projects or features between our standups and it can be quite hard to remember everything that I’ve done in the meantime. one of my most treasured hacks for this problem is the wonderful git standup extension. It lets me know exactly what I did in the past 24 hours on each project, not just how many or which tasks I touched on.
Another trick I’ve come to develop a love-hate relationship for is the art of shortcuts. I know, I know, this isn’t really some breakthrough insight, but just hear me out. It’s truly bothersome to learn the shortcuts of a tool, especially if you’re already proficient in using it, but trust me, it pays out in the long run. But why not take it a step further? I found myself wondering several times if I had any other repetitive tasks that could be automated or sped up with a shortcut or alias, so here are the ones I devised myself (and some borrowed from the internet, sue me) and that I use most often:
- show/hide fullscreen terminal on screen with CMD + § (or any other esoteric symbol/key you don’t use often)
- git aliases (
git gudandgit bcpare my favorites)
# Have fun
Last but certainly not least, if you’re not having fun while doing it then it might not be worth doing. Perhaps you’re not in the right environment, or don’t have the right mindset for it, perhaps you’re just not cut out for it. Whatever the reason, personal happiness should hold a great deal of importance when weighing one’s choices.
# That’s all (for now)
Of course I could write some more lessons, tips and tricks, but this post is already lengthier than I’d first envisioned, so I think this is as good a place as any to end my rambling. Hope you enjoyed, learned something new, share my mindset or just came along for the ride. Until next time 👋
Originally published on Medium