I’ve been reading recently a story on Hacker News about a programmer who
(depending on who you ask for a diagnose in the thread) was suffering from
burnout. Some commenters even suggested depression. There were many
advices recommended (unfortunatelly I can’t find a link to the discussion
right now) but one certainly spot my attention.
When you work remotely, you want to have some kind of a standup meeting regularly. In our team, after experimenting with many different approaches, we settled with text-based, asynchronous standups every day. Additionally, every project has a weekly ‘sync’ meeting.
What we mean by working asynchronously is not to always work async, to avoid meetings and video calls at all cost. But to rather prefer async way of communicating when it is favorable, when you are sure that sync discussion wouldn’t bring you much more. At first you might think that it is almost never but if you keep pushing yourself a little bit you will soon start to realize that you are getting better at it. In fact now we have much more async discussions than sync discussions.
We are Arkency and we have been working remotely since the very beginning of our company in 2007. Remoteness is a core value for us. If you opened the email, I hope you are at least curios as to why and how to work remotely. I think it all starts with dream and vision.
There are still companies which disable the website during deploys with database
migrations and believe that db migrations prevent them from going fully with CD.
They even have time window for triggering such activities (usually early in the
morning or late at night).
If you are working in a place like that, and you would deeply want in your heart to
adopt Continuous Deployment but you can’t find a way to convince your boss, this
is a step by step guide for you. Instead of going from zero to
warp nine, you can go towards your goal
with small steps that can be part of your current, normal tasks that you are doing for
One of the challenges of managing software projects is delivering big features.
We already told you that we prefer to work with small,
prioritized and unassigned
stories that anyone can take and finish. But how
do any up there? Especially, if what the customer comes to you with, is a big document,
describing the features that you must implement.
There is such moment in developer’s life when you start looking for a new job, sooner or later. You can observe that even in Poland, there are plenty of Ruby on Rails job offers, often in very perspective companies. I probably could find interesting job in Poznań, where I live, but there were some presumptions which pushed me to apply to Arkency.
When working on any project (personal or professional) we are always confrontend
with tremendous amount of tasks that bring us closer to the goal or let us
finish the project (many, many times there is no such a thing as the end of a project,
just years of long, ongoing, constant improvement of the process and code).
There are two ways you can look at it…
We recently talked how small
tasks can help you manage the risk in the project. In short: they help to
guarantee that despite the obstacles people keep working on the most important
But to take most from such
approach we need one more rule. Let’s talk a little about it.
As with software, improving your company is an ongoing process consisting of
multiple small steps. If you want your company to be more remote-friendly it
is also not all-or-nothing decision. You can gradually start using techniques that
will bring you closer to your goal. This series of blogposts is not about
why you should go remote, but rather how. Also, we believe that those techniques
will help you even if you are not planning to work remotely.
The first part was about having very small stories
and how it helps everyone track progress and provides closure.
Today we are going to talk about leaving tasks unassigned instead of delegating
them to particular developers at the beginning of an iteration.
In one of our projects we decided to try a lot of new things in the area of
project management. One of the most beneficial change that I noticed was using very,
very small task as the primary tool to assign and track work.