1

How do you prevent logarithmic productivity?

Profile picture
Software Engineering Intern at Taro Community5 days ago

Every time I work on a project, the amount of progress increases logarithmically. This means I start off really strong and I end off really weak. I’ve noticed this for a majority of projects that I work on.

I think a big reason why this happens is because when my project is able to get 50-60% of cases (ie it works but don’t touch it), internally my brain feels like it’s done and I don’t want to work on it anymore. When I start off a project I get huge boosts in dopamine when I finish a part and get it to work. Over time there are fewer and fewer things to do and I don’t get as big a dopamine hit when I gradually finish up remaining features. This gets really ****bad when I try to think of edge cases, because it’s not entirely clear what needs to be done, and I don’t even know what edge cases exist.

This has affected the quality of my work and I would like some strategies of keeping high output even towards the later stages of a project which involves less excited parts of work.

I think this somewhat relates to Alex’s video on “sweating the details”, but I feel that the hard part is that I don’t even know where to begin. I don’t know where edge cases may. On a component level it’s not too bad, but when you’re doing integration testing and when the space of possible inputs is extremely high, it feels like you’re put in the middle of the ocean.

As an example, recently I was tasked with writing a bot to draw an ordered set of lines, curves and arcs on a canvas. The input a vector representation of the drawing and the output is an mp4 recording.

First 3 days went pretty well. In fact, I pretty much built the entire system and integrated everything. The annoying part comes to solving edge cases from integration testing. For the next 7 days I spent days kind of just sitting around, testing my system, and getting bored. I was waiting for my partner to finish his part of the system.

What strategies are there to make my output more consistent? I tried doing a test plan but they tend to be really shallow because I don’t know how the system looks like/what edge cases look like until I’ve actually built the product.

31
2

Discussion

(2 comments)
  • 2
    Profile picture
    Software Engineer @ Verily
    5 days ago

    The way I see it, you need to define the scope and get it finalized with stakeholders. At Amazon and Google/Verily, in the design doc review, a lot of these issues are caught.

    Also think of Agile, not Agile(TM) as your friend. Test out the product as a user iteratively.

    Also, make sure to communicate that all edge cases cannot be seen immediately. So you will need skaffolds to detect edge cases that a user encounters. Look at fuzzy testing also.

    Once done make tasks.

    Look at the tasks to see what is the progress. Also make tasks for all launch approvals and stuff.

    The big trap is thinking that the MVP is the project. The initial MVP should be about 20% of the project. Think of it this way, you made the initial bot in 3 days. That means anyone can compete with you in 3 days. The rest of the 80% is what is actually competitive. Lines of code is not actual productivity. Meeting customer needs and giving that a good experience is.

  • 0
    Profile picture
    Tech Lead/Manager at Meta, Pinterest, Kosei
    4 days ago

    One thing that helps with this problem for side projects is to some version of submit or publish as quickly as possible. For example:

    • With a mobile app, I'll try to have the app published in the Play Store as quickly as humanly possible.
    • For a large code change, I'll run the existing integration tests very early to ensure I know how to do that, and I'll write out the test plan/summary even before I've written the code.

    Basically, if you remove the ambiguity about the final stages of the project, you remove the "what next?" question that can derail lots of people. This can help rescue you from the feeling that you're in the middle of an ocean -- you start to see the land!