This blog entry marks Day 5 of the EDOCODE Advent Calendar! In the previous entry, my colleague Iuchi talks about returning to work after taking paternity leave.
Why Write This?
Everyone at Edocode is writing a blog entry this month, and I thought I might as well use this opportunity to do some reflection on my time working as a software engineer over the last year and a bit. In the spirit of "teaching what I most need to learn”1, these are just some tips I wish I'd known before starting out, and writing it out is a good way to remind myself so I don't forget 😄.
Expectations at University vs at Work
The first thing I noticed was that university and work are completely different. In university, students are trained to keep deadlines. Semesters consist of overlapping courses and there will be times when multiple classes will overlap and you'll have a mountain of assignments due all at once. There is freedom and flexibility – after all, you are your own boss. You've probably stayed up the night before, trying to finish an assignment or to cram for an exam – I certainly have. All of this in the name of learning how to best manage your own time.
At work, however, deadlines are generally negotiable. After all, in real life things rarely go as planned, and plans themselves change all the time. In the face of uncertainty, being open and transparent is extremely important. If you're struggling, trying to hide it is one of the worst things you can do. This goes against your intuition as a uni student, where students are usually punished for not knowing things, be it in exams, quizzes, or code interviews. I will admit this shift in perspective was hard for me at first. I'm generally quite an anxious person, so being open to my colleagues about what I do and don't know is really quite intimidating.
This brings me to my next point.
Don't be Afraid to Ask Questions
Since you're new, and even more so given you're a grad, no one really expects you to know anything – Within reason, of course. You did get through the interviews! But with specific things: how the code base works, how to use specific tools, how the project is organised, esoteric programming language knowledge, etc., no one expects you to know any of that. So you don't need to expect that from yourself!
In actuality, this is more of a blessing than a curse. If you work in a supportive environment, you should never need to worry about not knowing something. So the logical thing to do, is to ask as many questions as you can! This goes against the instincts of wanting to seem smart; the fear of looking stupid. Apple's Craig Federighi gives out similar advice: never stop acting like the new one on the team. I guess it’s worked for him!
Again, I'm pretty lucky that my teammates are very helpful in answering my - mostly silly - questions.
Fight the Overwhelm
The next thing you'll probably notice, after settling in, is that software development is really hard. But not necessarily because of technology itself. Rather, things are really hard to define and we don't always know what we want. Of course, the goal is to make “Software that Just Works!™” but a lot of that is trial and error, and you can't escape this no matter how well you plan.
What this means, (besides inspiring existential dread,) is that without guardrails things can quickly spiral out of control. Indeed, many of the popular methodologies of software development exist to rein in this chaos. For instance, the Agile methodology says you don't really know what you want to build when you start out, so its best to quickly build a minimal viable product (MVP) first and then iterate on it as you get feedback.
You can apply this approach to work at any scale. For instance, in my day to day work, we write a lot of tests (the TDD way). A journey of a thousand fully functioning web pages begins with a single button. A test, written for that button, in fact, to check if it is on the page. It will fail of course, because you have an empty page. But making that test pass is trivial: you just add a button – that does nothing for now. And then you go on to write a test to check if that button does something when you press it. And so on.
I've found that this approach of breaking a huge project down into bite sized pieces has been immensely helpful in being and staying productive.
Soft Skills are Important
It is really tempting to think that you are defined by your hard skills; the code you write. I've since realised that your work constitutes everything that you do during your working hours. This includes the meetings that you attend, and the often emoji filled slack messages you send and receive. All of these constitute work, so you need to be professional. Now that doesn't mean being insincere or pretending to be anything you're not, or anything unpleasant like that. It just means being polite, responding to communication in a timely manner, and just being honest too.
All in all, you should take your 'other' duties just as seriously as writing code.
Problem Solving
Soft skills comes in at a close second, but the most important thing – and the one you're paid to do – is to solve problems.
At the most fundamental level, when making software you're asking yourself: how do I build that? How does this thing work? How do I write the test?
But don't stop with the code! Try extend this thinking to everything else you're working on. Think about the product you're making. Why is it useful? How are our customers using it? How can we make it more useful? Wouldn't it be cool if it could do xyz?
Now, think about how you're working – how your team is working. What's going well? What can be improved? Why are we doing things this way? Is there a better way?
For me, this part of the job is what makes it fun. Of course, we do this in our weekly retros, but it's good to apply this thinking wherever and whenever you can.
Outro
I'd like to finish with my favourite software engineering quote:
One hundred years from now, our engineering may seem as archaic as the techniques used by medieval cathedral builders seem to today's civil engineers, while our craftsmanship will still be honoured. – The Pragmatic Programmer2
And that's it! Thank you for reading.
Tomorrow, my colleague Yuping will discuss improving the onboarding process for PUSHCODE. Check out future entries here! Also, if you’re interested, Wano group is hiring!
Original quote from Richard Bach: “You teach best what you most need to learn.”