HN user

mzanchi

18 karma
Posts5
Comments16
View on HN

Keep a document of your design decisions. It's very tempting to hack away to get things done, but human memory is short and feeble: you will forget why stuff was coded the way it was faster then you think.

I usually keep a Google Docs page open where, as I write the code, I update the documentation. It keeps things consistent and flexible, and much easier to go back and refactor.

For me particularly the greatest difficulty was in understanding what was going on, and how people's effort was contributing to the company's goals. There always seems to be a lot of activity on individual tasks, and project managers will take strong interest in making sure that their project is on track, but higher up the chain of management I have always had trouble seeing where all the pieces fit together.

I would love if it was possible to have attributed to everything that is done in a company an array with scores that will indicate how well that effort is a fit for the company's goals. Then it would be simply a matter of having sensible metrics and an easy way to get the information. I imagine that's what KPIs are supposed to be doing, but somehow there doesn't seem to exist an easy to implement strategy for making them effortlessly intuitive and useful.

BBC Sound Effects 7 years ago

My dad had a vynil LP with BBC sound effects, which I remember listening to when I was a kid. I particularly liked to listen to the disaster sounds, like cars skidding and crashing and, shockingly, a crowd of people being shot at.

Yeah, I started doing 1-on-1 with all of them when the team was about half size. The reason I got one of the guys "promoted" as dev lead is so he can take most of the mentoring and feedback gathering. He is not their boss though, with no authority to assign work or make demands.

Nowadays I do 1-on-1s with the dev lead, the assistant, and the product owners (senior devs and architects), so only 5 people.

Still, that would mean the dev lead would need to do 25 1-on-1s, so we have a structure of peer mentorship, with two phases: a formal and an informal. The formal is to maintain quality of information gathering and fairness. The informal is to allow for rapport and flexibility in the part of the mentor. We started this recently, we'll see how it goes.

This has been in my mind recently. I am head of development at a startup and have something like 30 direct reports. I don't want to be doing this job for a long time, and am maneuvering the team structure to make myself redundant with the following actions: - I am trying to convince the execs and HR to increase pay transparency and to reward people who want to progress in their careers as engineers more than those who want to become managers. - I have promoted one person with more leadership skills (and less technical ability) to be a dev lead; essentially a mentor, gathering feedback from the team and helping them solve process and communication issues, and keeping track of OKR metrics. - I hired a department assistant, to do resource allocation, manage Jira permissions, tidy up boards, etc. - We have 1 project manager who is responsible for our three internal development projects, controls our budget and fights with other PMs for resources. - All others are Developers and QA. Some are more senior, so they have architecture roles. Everyone gets to give their voice, but one of them has an official role of architecture lead, who has the final say, but that's mostly cerimonial.

My role is to help them focus when they start to drift, shield them from politics, and most importantly give a cerimonial ratification on their ideas, if they match the values of the company.

So all 4 non developers are essentially assistants. I hope to soon be able to step out and leave the team working happily with a 10 to 1 ratio of dev to non-dev.

I never give any information to anyone who calls me, apart from people I already know like friends and family. If they say they are from the bank I apologize and say that I will contact them independently via the number that is on my card. I don't even confirm my name. Some banks think I am being difficult, but I stick to this principle regardless.

It's interesting the author mentioned estimating but said they are not very good at it yet. I have read somewhere else that what distinguishes a senior engineer from a junior engineer is exactly the skill in estimating work.

I'm a maths graduate who became a programmer too. In my experience there's very little direct application of the knowledge acquired during the degree, but the thinking process gained is totally relevant. Doing a maths degree is one of the best things that happened in my life, and it altered the way I think forever. Having said that, now that I do a little bit of AI (as everyone should), I start to see more and more math in the code I write.

One comment regarding the "embedding". This is similar to the Toyota concept of the gemba, or being where the value is produced. For automobiles, that's the factory floor. For software shops, that's with the developers, testers and BAs.

You want to be able to understand the work flow of your staff in order to catch opportunities for continuous improvement, and the best way to do this is to observe the work being done, but in a respectful way, that is, respecting the staff space and making them comfortable that you are not there to observe them, but the work.

I really don't understand why a manager would want to have an office in the 21st century.

I have the good fortune of living in Vietnam, so all this happened while I was sound asleep, and when I woke up I read the rejection email first, as it arrived later and was higher up my inbox. Time for coffee and back to coding.