Engineering Productivity

A few months back I switched companies. For me this means new team, new domain, new programming language, new tools. After starting with my first project I quickly learned that I had a lot to learn.

Waiting

I am working on end2end tests of a web application. If you ever worked on this you know, that end2end tests are very slow.. Because I just started with the programming language (actually this was my first code I wrote in it), I made a lot of newbie errors. Missing imports, missing semicolons, … But the tools I thought were standard didn’t do auto imports or highlighting compiler errors (this does not mean that they did not support this, but I definitely used them wrong). So I always run the build command just to learn 30seconds later that I missed something obvious. When finally everything compiled, the tests were failing. I was also new to the testing framework, so I did not know all features that were supported nor how to use it properly. I need to do some trial and error.

After spending a whole afternoon waiting, I felt very frustrated. I am working in an engineering productivity team. This was definitely not engineering productivity. I want to consult people and support them in being more efficient, but I was not able to be efficient myself. Not even close.

Increase Productivity – The Power of the Debugger

So I decided to spend the next day to work on my developer setup. I read the documentation and guess what, they were suggesting a different IDE. After setting up the IDE I felt relieved. Compiler errors were displayed immediately, as well as missing imports. This alone would save me hours. I learned how I can execute single test cases (I already knew how to execute single test files but running single tests increased the build runtime even more).

I asked the dev team how I can reduce execution time and got a few more hints. And then I realized that I could just debug the test and evaluate expressions and scroll threw the object instances on the fly. Suddenly I was pretty fast compared to the day before. End2End tests are still slow, I’m not able to change this (at least not in short term), but getting to know the tools, their features and how to use them increased my productivity a lot.

In the past I met some developers who just lived with such a situation. “It’s slow, what can I do? That is how it is.” and they waited and waited (and complained about the slow end2end tests and that they do not want to write more tests). Don’t do this. Invest a few hours to make a good setup and learn about the recommended tools. Afterwards you are much faster and much happier.

Every programmer likes different things. I always enjoyed developing tools for the team, automate things and make the developers live easier. A few months ago, I finally stumbled upon a term which summaries all of these things I’m passionate about: Engineering Productivity 💕

Of course it doesn’t make any difference if there’s a term for something or not. But for me it felt like ‘I’m not alone’ and ‘This topic does exist’. And of course it is much more easier to phrase what I really want to do.

But as always, everyone has other things in mind when they hear about Engineering Productivity. There is no one official definition. So let me explain, what Engineering Productivity is for me.

What is part of Engineering Productivity?

Engineering Productivity aims to help developers to deliver high quality code as fast as possible. Most of the people think about Engineering Productivity as setting up environments quickly or have the right test tools and metrics. Of course this is all part of it.

For me it includes especially the following topics (in no specific order):

• Setup
  Easy setup of a new project with CI/CD and everything you need.
• Coding
  A useful IDE, easy to setup for new team members and all necessary plugins. (If there is one necessary plugin missing, I’m happy to implement it. 😉 )
• Process
  Of course the whole process is important. Which meetings do the developer have? Are they useful and are the intervals useful? Where do they loose time because they have to wait? etc. Sometimes things are done because “we always did it this way”, it’s always worth to think about how the process can be improved.
• CI/CD
  One of my favorite topics. Everything possible should be automated. You should test as much as possible with a minimum build duration.
• Debugging
  You should have all the tools and knowledge how to debug efficiently. During debugging a lot of time is wasted. Sometimes this is good, because developers learn a lot while debugging. But sometimes it is just a bad setup or a lack of knowledge.
• Monitoring
  Developers can fix bugs easily if they are discovered quickly. With a good monitoring you will see errors or increasing response times very fast and hopefully can fix it or roll back. Tools for monitoring are sometimes underrated. You need to have a good dashboards and links to further information when something goes wrong. Developers don’t want to waste time by searching through a dozen of different systems.
• Testing
  The code should be easy to test. For this you need a testing strategy, maybe some testing frameworks, sometimes testing patterns are useful. What is a unit test? When do I want to have an integration test? How to test the front-end, the database, all different devices and which test environments do I need?
• Documentation
  To be productive you want to find answers and explanations quickly. So documentation is also part of Engineering Productivity. This does include Architectural Design Records, Bug Tracking, Root Cause Analysis, Diagrams, Backlog, etc.

You see, Engineering Productivity is a very wide field and I really enjoy to improve my productivity and the productivity of the team.

Do you miss something? I’m happy to learn about all the areas you think about when you hear Engineering Productivity.