Primary and secondary tasks
The main focus is programming and solving problems. But that means that everything that obstructs this focus, needs to be gotten out of the way. This is simpler on paper than in reality and therefore there are multiple “faiths” among company, how to do this.
We start with clearly distincting primary and secondary tasks, where the difference is that there needs to be more time spent on the primary tasks in the long term. The last part of the sentence is very important.
What we do every day and week:
- Planning
- Write issues
- Make issue estimations
- Prioritize issues
- Bundle issues in epics
- Pick issues for personal weekly milestones
- Problem-solving
- Coding and math
- Learning
- Reading books
- Reading papers
- Watching videos
Why so much emphasis on planning?
The planning-part takes good time, but refrains us from spending too much time on dead ends. And spending time on dead ends is not a primary task at all. Also planning helps with designing better strategies – there is limited time for solving problems and coding software, so doing a full-scope research is not going to work. As there is no way to efficiently build complex code without any time-estimations on the different approaches, planning-skills provide the necessary foundations for becoming a senior coder.
We start as early as possible to train these skills, so also juniors are asked to do all planning-tasks. Initially this takes a good part of the valuable coding-time but quickly goes down and first advantages are seen.
Style of project handling
Tools
We mostly use Gitlab and Mattermost to share code and have discussions. This makes it possible to keep good track of each project – searching for what somebody said or coded two years ago is quite easy. Using modern tools has changed the way we work a lot, thus we have questioned and optimized everything that was presented as “good practice”.
We continuously look into new tools that can help us improve. Also here the main focus is to reduce the time on secondary tasks, so we can spend more time thinking on problem-solving.
Pull-style project management
The tasks are written down by the team, using the project-doc as input. All these tasks are put into the task-list of the project and estimated. Then each team member picks the tasks that are a good fit. There are always tasks that need to be pushed instead of pulled, but luckily that’s a relatively small part of all work.
All code (MR) is checked by one or two colleagues, chosen by the one who wrote the code. More important are the discussions in advance, as the group can give more insight than any individual and one can get into the task well-prepared. The goal is not to get the job finished, but not having written the code where a future bug has been found.
All types of code can contain comments and Doxygen can create documentation automatically, so there is no need to copy functions into a Word-document. Log-style documentation was introduced, as git history and Doxygen don’t answer why a certain decision has been made. By writing down a logbook, a new member of the team can just read these remarks and fully understand why the architecture is how it is and what the limits are. We’ll discuss this in more detail later.
These type of solutions describe how we work and differ from a corporate environment: no-nonsense and effective.
The week
If you’d work here, how would your week look like the first year? Specifically saying the first year, as for more complex projects, different approaches could be chosen.
Monday weekly planning
Together with your team you pick up the issues for the week. The issues should have estimations, or these will be done during that meeting. When your week is filled, you know what to do.
Monday weekly meeting
Every Monday we have a weekly meeting to share with everybody how the other projects are doing.
Mon-Fri: Daily standup
Retrospective of the previous day, and tuning of the day ahead.
Practice:
- Tools
- C/C++
- GPGPU
- Scrum
Friday closing
Weekly retrospective, cleaning up, writing notes on issues, etc.
Weekly customer meetings
Here we discuss the progress and anything blocking. The customer shares their progress, and together problems can be solved.
Many projects have a shared (high-level) issue-list, so the progress is continuously synced with the customer and communication is easy.
