Unlearning is one of the hardest parts with any transition. You bring with you many years of experiences, expectations and biases. These have built up over time through different work situations you have adapted to. Past experiences allow you to hit the ground running when it comes to work and communication. They can also be heavy baggage, slowing you down. In a startup this baggage could be the very thing that’s holding you back. You’re looking at completely new problems with views that don’t match your situation.
Here at Dolittle, we’re hitting refresh on many of our previous assumptions. Looking at old problems with fresh eyes. How we approach our coding practices. How we are working with customers. How we are approaching contracts. How we are building products. We’re re-learning, and allowing our culture to grow.
“If your mind is empty, it is always ready for anything, it is open to everything. In the beginner’s mind there are many possibilities, but in the expert’s mind there are few. ” –Shunryu Suzuki
An example is communication. Coming from a very distributed team, a few of us wanted a more formal process. More documentation, more written communication. This is important down the line as we grow, but not so much in the beginning when priorities change almost daily.
Hitting refresh is an important part of starting anything new. Making it explicit that you need to take a step back and reconsider your expectations. You’re going to have new problems and you can’t deal with them if your focusing on solving the problems you had in the past. At the same time, it’s importatnt to leverage universal learnings and principles. It’s also important to recognise the context in which those are valid.
Are they really valid to you now?
Photo by rawpixel on Unsplash
This post appeared originally on the Dolittle blog
The feeling when you hit the button and push the code to server. You’re done! You’ve implemented a new feature that’s going to be ready for the end-user. Soon. You see that the code has reached the build machine, and a new build gets scheduled. You get up to take a quick break and end up chatting with a few colleagues on the way. When you get back you see there are 10 messages in your inbox and the same number of notifications on your team chat.
Looking around, you see that the scheduled build has failed. And now there are 5 other schedules builds that ended up failing. It looks like you’ve just broken the build. The rest of the team of 20 developers are now blocked from committing in their code.
You sit down feeling… Continue Reading
Using tools like GitHub or BitBucket allow developers to able to submit their changes through pull requests. One of the challenges with pull requests is that they often contain very little information, apart from the change itself and perhaps the issue or case in question. Bad pull requests make the lives of reviewers a lot harder, and mean they need to spend a lot of time understanding the context. Instead of focusing on the change itself.
So, how can you improve your pull requests? Continue Reading
I’ve been fortunate enough to be interviewed on the Legacy Code Rocks podcast. We had the chance to dive into empathy in software development and cover quite a few topics. I feel it was a really good conversation and I learned a lot. Hope you enjoy it! Continue Reading
When working in a team trying to deliver software things don’t always go right. Quite often they actually go wrong. Sometimes though they go so wrong that there are consequences for others. And when things go wrong, someone is to blame.
It’s natural to protect yourself and make sure all attention is on the next person by blaming and pointing. Perhaps you just sit idly and let others deal out blame and this helps you get by on a day-to-day basis. If you and the people around you are dealing out blame, you aren’t only making it bad for those around you, but for yourself.
Dear Lone ‘Team Player’,
Welcome to our team. We care about working together and improving as a whole. We know there are some challenges with the codebase, but are gradually improving as we deliver functionality. Continue Reading
You’re sitting there, writing code for another feature request and a message pops in. You know it’s important, since it’s a direct message. You glance at the notification and see the words:
Dev: “You broke the build…”
You click the notification and get taken to the 1-on-1 chat, where you read:
Dev: “You broke the build, you fix?
Short and to the point. An efficient message. Perhaps not the most effective though, since you’re sitting there and scratching your head. You’re feeling annoyed. Not because you broke the build, nor that this person let you know about it. It’s because you can’t seem to get hold of the feeling of the person behind the message.
Are they irritated? Maybe mad? Possible stressed out? None of the above? The uncertainty of this can easily put you in a negative state of mind, and that won’t help with collaboration. Continue Reading
Working as a developer involves communication on many levels. We need to communicate with business stakeholders in a domain specific language, abstracting away much of the technical jargon. Team communication on the other hand is a lot more technical, and closer to our reality in code.
A lot of our communication is silent though. It happens through async tools like email, Skype or Slack. I’m sure that anyone that’s attempted communicating this way has experienced how easy it is to under-communicate, leading to a ping-pong of messages before the intent and understanding is conveyed.
The end goal of all this communication is software that delivers value to users.
Software isn’t finished when it’s been delivered though. It changes over time and with it loses its original intent. This leads to even more async communication, which can go over months or years. I’m talking about the communication that happens through the code we write.