7 insights I gained about SW development while learning how to code (coming from a product manager)
In my 10-year career of being responsible for a product in one way or another, I gained a fair share of experience of what to expect when leading development teams, them being either HW or SW oriented, projects varying in size from 2 to 25 developers with millions of lines of code (heck, once I juggled between four teams from The Netherlands, Italy and the Czech Republic building three products at the same time, but that is a story for another day).
Nevertheless, one is always learning, and here are some key insights that I got while I got re-excited about coding in the last couple of months; facts about SW development that I would have a much harder time gaining without “getting my hands dirty ” with my hobby projects that are now (slowly but surely) evolving into real products.
1. Know your technology (Sometimes you just can’t write good enough specs)
I would always say that I knew technologies used and by that I mean that I was able to hold a conversation about any particular coding language for 5 minutes, understood database normalization, the importance of reusability, and so on. Now, after working with my mentors on my code (all of them are senior developers) for the last half-year, understanding now-common deployment flows, coding principles, sequences of data processing, etc., I am only starting to grasp how diminished my knowledge was, technology-wise. I take this realization as a good thing (I guess it’s better to realize something now than when your 64, right?) and I cherish great VP Engineering skills even more now, one that can provide value in translating user needs into a properly coded app. Now, I would write my specifications differently (I still support user stories 100%) and more importantly, I would hold different conversations with developers before development and would rather be another opinion in how a feature will be developed than leaving it solely to them, as this could lead towards preventing some potentially costly functionality reverts and missed sprints (now I truly understand CTO delaying development due to inappropriate models, data sent over REST APIs and the correct naming notations on my past projects, thank you for not letting them go easily, Marko).
2. Be quicker in defining MVP (minimum-viable-product) and OOS (Out-of-scope)
I used to approach a full functionality description in either Google Docs, or Confluence, covering all corner-cases, that I could think of. While this was good, and while I still support that, I can now see why developers sometimes thought of it as overkill. While you haven’t touched the existing app implementation, you don’t know what kind of a ride you’re in for and sometimes my corner cases would be solved by using an appropriate out-of-the-box component and setting it correctly (my comments were sometimes self-explanatory, a l’art pour l’art in retrospect). Next time I sure won’t describe these corner-cases in-depth but will just provide bullet-points with core functionality and will wait for the first app draft to test the developer’s vision out and refine from there. We may not be necessarily faster, but I will spend way fewer resources on an initial documentation creation process. Leave things OOS for the time being and include them only, if necessary while trying to live as lean as possible.
3. You are always refactoring
One unnecessary thing that was always blocking my teams was refactoring. Mainly because my first developers were such a stellar, world-class type that hid any refactoring from me and packed it neatly into new functionalities they provided (shoutout to Robi and Peter). I always thought of refactoring as a once-a-year thingy where the team would spend one sprint making sure the stuff is future-proofed, but now, after the third major rewrite of my autonomous camera’s SW, I think I fully understand that you just can’t avoid refactoring, but that the time one spends on code-improvement can be better spent if you can include some new functionality in the process. Additionally, and code improvements that increase the project’s readability and make it easier for onboarding new team members are crucial and should be applied asap. As one learns new technologies available, the first take will usually be dirty and will need improvements soon (PEP8, you were my nightmare and we are slowly becoming friends as I understand why you are there). My app went from 800+ lines of code (on which I was incredibly proud) to 400 after a first and to 268 on the second rewrite. I believe its wise for every PM to calculate a rewrite sprint + some low hanging fruit (functionalities) in every 4th sprint and evaluate whether that is necessary as the timeline goes or at least after every major functionality. Anything less will bite you in the back eventually and all of a sudden, there you have a month without a release.
4. One about things you don’t know you don’t know
Usually PMs with little to none development background believe somethings might be a low hanging fruit but as it turns out many times, that is far from the truth/reality. Be prepared for things to go wrong not for the reasons you know, but reasons that are unclear at the moment of feature planning such as “We need an API for that”, “Backend is not ready/doesn’t support corner case scenarios”, “Implemented designs don’t feel as good as they did in wireframes”, and so on. As one is writing up user pain, user story, or general documentation of a new feature, she comes from a positive standpoint, figuring a way for the shortest implementation timeframe. That can lead to pitfalls of missing crucial data/flow moments that can delay go-to-production date during development and testing phases because the great technology-, environment- or situational unknowns can arise during the development process. Count that in when presenting the next release to your stakeholders.
5. Never estimate This is easy, shouldn’t take you long to implement
Don’t you ever do that, there is no easy fix. I can see that just about everything I coded proved out to be more complex than estimated. Projects that I said will be done until the evening turned out to be much bigger (in scope and complexity) than initially expected, turning that evening into days and potentially even weeks. I just couldn’t estimate it at the time when vision was put in my Trello board and now I fully understand why Jira story can break it down into tasks and why new tasks should be added during the sprint as new things will arise that developer will have to deal with to release the functionality but will take her much much longer than initially expected as if released without, you as a PM will not be satisfied with. Plan and allow for some stories to be expanded beyond stories-to-tasks breakdown during sprint planning. And, as a team, get better at estimating stories as a whole.
6. Developers are too optimistic, and so are you
So far the only mantra that is true for just about every developer I worked with is that they are too optimistic and that is meant in a good way. Like everyone, they believe that things will be fixed quickly, deployed without a problem and that all the bugs will be solved with ease and in no time. Like in point 5, I was always supportive, but kind of nagging about the fact that everything was available later than promised but had to learn it the hard way. The fact that I had to implement a simple feature like getting sunrise information based on geolocation or place current GPS tag on the map proved to be harder than expected. And after that came multiple device feature testings (that I didn’t count into my feature estimation). And after that came site stability testing (didn’t think about that one either, but it had to be done). After this pattern got repeated over and over again, it got me thinking and I led me back to the Smartninja JS course I took in November 2019 where mentor Jan held the final session in which we (a team of 5) had to build a BMI calculator with a couple of “fancy features” in 60min. As we failed to do that in time, he gave us extra time and after two hours, he stated (looking at me, rightfully so):
Can you see how easily a feature would overcome an original estimations? You just spent whopping 100% more of the time that was originally allocated for this, can you imagine how expensive this would be for the company, long-term?
It got me thinking and while I didn’t grasp the comment in its entirety then, I sure do now and will act accordingly in the future.
7. Even a great developer can get stuck in a problem
And as I am not a great developer, this happens to me even more often than usual. I think that I have a solution and then spent initial half an hour implementing it, find a problem, search and try different solutions, talk to mentors (as they are available), walk away to clear my mind, “wasting time”. So far, if one takes enough time, the problem will be solved, but keep in mind that only a handful of developers I came across in this past decade, had most of the answers on the questions present and could create solutions fast and mostly without problems, while others got stuck here and there. Another pitfall is not asking for help fast enough, as PMs, we have to regularly check on progress and it helps of a product manager can “speak code” despite that remains team leads responsibility. IMO it’s better to be slightly annoying than missing the deadline. One can only understand the struggle if it lived it and I sure understand it now.
Another wisdom from Jan is to be more supportive and patient towards less-experienced developers:
If hourly cost of your senior developer is X and junior developers cost is X/10 that means that he could be working on the same problem 10 times longer than the senior, so it’s ok to assign him functionalities where he/she could learn and allow her to spend the first half of allocated hours searching for a solution. If she fails, she should still complete it in the next half of the time with a bit of guidance from a more experienced developer, all that WHILE senior developer develops a feature more crucial for the project. As a bonus, all the time the junior developer will spend searching for a solution is an invaluable learning material that she would be robbed of if she would be pinpointed towards the solution in the first place.
As I just started to walk the hobby development path again, I am grateful for these realizations and will, equipped with these insights, be more patient, understanding, and hopefully better prepared to answer developers’ questions for future projects. Can you share another insight I forgot to mention?