00:00:18.400
I would like to introduce to you the three gentlemen: Robert Pankowecki, Alex Koppel, and Michał Taszycki. Please give them a round of applause; they're very shy. So, here's what we're going to do: we will have a discussion, but in the second half, we will turn this panel into a fishbowl discussion. This means they will talk about programmer productivity, and in the second half, we will invite you to come up here and also take part in the discussion. I will explain the rules later.
00:01:05.400
Hi, my name is Robert. I used to be one of the organizers last year, and I have some notes with me. I'm going to try to troll you hard, and I hope you will troll me even harder. Today, we are going to discuss programmer productivity. Usually, we want to improve our productivity, but you can't get better at something if you don't measure it. So, the first question is: how do we even measure productivity? This seems to be a very hard thing to catch.
00:01:41.799
Shall we sit? We'll be more comfortable. So, how do we measure productivity? Yes, I should know that. How do you know if we’ve improved at something? I mean, we want to improve, but how do you know? We need to measure it. My idea of measuring productivity is that first, you need to define what you need to do. For example, we could measure it in lines of code, which would be ridiculous, or measure it by the speed of closing tickets, which could be fine. In general, I try to set up some goals at the beginning of the day or the week and then see how many of those goals I have finished. I see what I can improve from there. There are some tools and techniques that can be used to facilitate this, but we can discuss those later.
00:03:09.840
I agree with what you're saying. To expand a little bit on that, I think measuring productivity is a really difficult problem. People have been working on it for a long time, and I don't think there's a simple, discrete way to measure it by just putting in a bunch of inputs. In the end, it is a subjective measure. The business will set out some goals, or you’ll set out goals for your own project. Then, you’ll ultimately see how quickly and how well you meet those goals. Productivity is not an end in itself; we want to be productive for a reason. For example, our clients want us to be productive so they can meet their goals or launch a product.
00:04:50.920
If I measure my lines of code, how do I know it's the right metric that provides value? If I can write twice as fast, how do I know that it provides any value to our clients? It’s crucial that we choose the right metric. Speaking with your clients is likely the most straightforward way to determine productivity. They will tell you if you're being productive, and if they get angry that you aren’t, it’s a sign that something needs to change. Ultimately, measuring productivity should be linked to achieving goals and ensuring client satisfaction.
00:06:17.040
The feeling of being overworked or unhappy can also be a metric of productivity. If you feel miserable, tired, or hate your job, that’s a sign you need to change something. Reputation can also measure your productivity—how your coworkers and clients perceive you. However, while these measures are indicative, they can be subjective. It's difficult to establish a simple measurement system for productivity because it can vary greatly from one context to another. We might be programming logically, but trusting our intuition about our progress can also be valuable.
00:08:52.160
The recent push to recognize programming as requiring real thought and creativity points to the fact that we are more than just machines delivering code. There are definitely programmers who do not want to measure productivity with numbers. Viewing velocity in project management tools like Pivotal Tracker can be useful, but in the long term, those metrics may not accurately reflect the real value delivered. You can deliver many stories, but if the product fails or clients don't convert, that productivity becomes questionable. Therefore, it’s crucial to focus on meaningful metrics that align with project goals.
00:11:38.280
Ultimately, productivity does matter, but we must also focus on the right tasks. Sometimes, even optimal productivity rates can lead to wasted effort if we're working on the wrong projects. It's essential to prioritize tasks accurately, and in my experience, it’s often better to take the time to do things right than to hurry through tasks that may not lead to success. However, improving productivity in mindless tasks could also be good if it means delivering faster results, even if the results aren't entirely useful.
00:14:12.200
A worker's well-being plays a significant role in productivity. We know that health impacts productivity; lack of sleep and unmaintained health can lead to decreased performance. Regular physical and mental well-being maintenance leads to better productivity outcomes. Happiness is an important factor as well—a developer's happiness often correlates with productivity. When a developer is happy, they're likely more productive, which in turn benefits the company.
00:16:17.000
On the other hand, some may argue that happiness is subjective and difficult to quantify. Metrics from tools, like code climate scores or lines of code, while not perfect, can offer some insight into productivity. Ultimately, it’s essential to consider the context and the outcomes. Instead of seeking a perfect productivity metric, focusing on removing obstacles and understanding what enables and inhibits productivity is vital. Evaluating the effectiveness of different methodologies—like Getting Things Done and Pomodoro—can help improve individual productivity. Personally, I find the Pomodoro method very effective. It's taught me how to focus better and has led to more effective work habits.
00:23:02.880
In conclusion, it's not just about how productive we feel or how much code we write; it’s about how that code solves actual problems and serves the project's goals. Each person's productivity should not solely depend on output metrics; the quality and relevance of the work are what truly matter. Thank you very much for your participation and contributions to our discussions today.