I’ve mentioned my approach to technical debt often, but I’ve never actually written it down. Here’s the framework I use. Technical debt is most typically brought up from individual engineers or the engineering department. If not attended to, technical debt can slow down future product development and reduce the developer experience. To me, technical debt is simply technical work we choose to postpone, focusing on something that currently has higher priority. ...
Acid House flyer with smiley illustration For some reason I have no urbanism topics or podcasts! Dave Kellogg brings an interesting perspective on leadership levels. It is an old article but still valid. He seems to be going against the stream in general. Worth a follow! Leadership Career Development: What It Really Means to be a Manager, Director, or VP - interesting perspective I agree on What we learned in studying the most effective founders - mostly as expected, but this is interesting: “While most people would expect self-confidence to grow with time, our data suggests the most effective founders are not nearly as confident as the least effective founders are.” ...
Back from my holiday and catching up with the news. New section on Agile this time as something at work required a bit of research into this. Management What’s going on with the ‘Great Resignation’? - I have heard this term in different contexts a few times now. I guess this will continue for a bit more. Building a data team at a mid-stage startup: a short story - example story about how this could happen and what to expect ...
Recently our CEO Raj Kumar spent a week in our Barcelona office where the majority of our engineering department is located. I was working on some ideas for him to meet the team and get some insights into our daily work. While most of the company is aware of UI/UX and front-end changes we are doing to our site, some of the back-end and infrastructure work can seem like black magic. I think it is important to take every opportunity to bring this output closer to the rest of the company and especially the leadership. ...
When I joined Devex a bit more than six years ago most of the code base was in one large monolith. This monolith was based on Ruby On Rails and was responsible for delivering devex.com. This part was called “neo”. I guess because it was a rewrite of a previous Java version. I am not sure if it was a reference to Matrix or the Greek meaning. There were already some initiatives in place rewriting parts of it in different services, but the monolith was always looming in the background. Any changes to it required increasing amount of work. It was like someone tried to put the definition of technical code into code. ...