What do you like about „Pair programming“?
For me there’s no other option. Pairing is not paying two people to do one person’s job, but having a conversation about what’s being implemented and discovered. By doing so, you’re having your first review while coding and the outcome is more valuable that way. Of course, there are some mechanical tasks which do not require creativity and can be tackled separately.
How would you describe a typical workday?
My day usually starts with reading some e-mails and reviewing my calendar for the following days. If there are no issues, I keep an eye on monitoring the health of the apps our team is responsible for. Then we have our stand-up where we align on expectations and share our blockers for the day. Sometimes we schedule a follow-up from a stand-up, and once decisions are taken, each discipline does its part. From then until lunch, we take turns coding our assignment. Usually, we take short breaks to refocus and discuss what we’ve done and what’s ahead. Once our lunch break is over, we continue with the assignment, reviewing any requests from other teams and providing support, starting with the high-priority tasks. I like to read some tech stuff while on breaks, and every 3 or 4 short breaks I take a longer one to stretch or take a walk to relax my eyes.
How much time do you have to develop your skills?
As a software engineer you always need to meet the new kid on the block: every now and then a new framework, paradigm or even language comes along. Having the time and will to know them opens your mind and can improve your toolset. Of course, you can bring innovative ideas to your daily job and at the end of the day, that makes you work better. Sometimes you start a HackWeek project using these new items, spend a weekend taking a course or watching a set of videos on the subject. Either way, I like to keep myself updated and try to grasp as much as possible. We also have some budget for training so you can attend a conference or take a course you’ve always wanted to.