Comment by mojomark | Hacker News Reader

Comment by mojomark | Hacker News Reader

Good read (reminder) and love the reference list.

Question for the OP. I suspect we're of similar tenure, and I'd love to det your perspective...

I'm a mechanical systems engineer in an industry that is growing from industrial automation to true autonomy (robotics). I've always liked coding, but don't do it enough to be a serious contributer to "production quality" code. Nevertheless, since last year I've transitioned from a more mechanical/hardware design firm to a much more mathy/software engineering firm. I find myself in a role, bridging robotics hardware and software teams working on a ~10yr old codebase. We have some great engineers! I've tended to stay on the customer requirements and algorithm development/analysis side of things, but I struggle with the lack of benchmarking and testing our group does, and I'm continuously surprised at the simple bugs we find that cause application crashes. Moreover, when a developer shows me code, I'm stricken by the number of undocumented "magic numbers" that seem like forgotten patches popped in there at one time to make things work for a test or demo, and the number if/then statements I see that are holding things together.

I'm also faced with a growing cry for "how can we best make use of these LLM things" (for which there are a thousand and one answers).

I see/feel the suffering, and what looks to me (from my 1000ft perch) like thousands of cuts.

Bottom line, I'm increasingly thinking that I really need to take a month and try tracing through the thousands of lines of C++ (which I haven't really written since grad school) in order to truly understand the state/configuration of pur code baseline so that I can provide some more explicit leadership in terms of - do we refactor everything that looks messy or the we don't 100% understand? Do we take a T.O. to build up our automated unit and system level testing? etc.

As a manager of a SW team, from your experience is it a good idea for me to dig deep into the code to gain an intimate understanding? That feels an awful lot like micromanagement to me, but I will do it if that's what 'wisdom of experience' in this domain proves is the most value-add.

If you can't understand it yourself, you will have to find someone whose expertise you trust to answer the questions for you. But you don't have to understand the software down to bits and bytes, just enough for you to make good decisions. Having pragmatic underlings bring up problems and propose solutions is what you want. Watch for idealists for whom everything is broken and needs to be rewritten. Incremental improvement is the way.

/me raises hand. idealist here, and I do want everything rewritten. Please ensure you provide your idealists with all business goals and limitations rather than shield/protect them. You’ll find that then their suggestions take those things into account

Thanks to both replies. There's certainly a time and place for refactoring, as there is a time and place for getting an MVP out the door. I guess striking a solid balance is the art of it all.

I am very transparent with business goals and the threats we face, and I do think that spurs the most engagement. It could be my rose colored glasses, but it does seem like everyone truly feels a sense of ownership and pride in the product. As someone who is very hands-on though, it's very scary not having full awareness of what's going on under the hood. However, I'm sure I can overcome that mental hurdle.

I appreciate the feedback/advice HN.

Not the OP but I'd say no.

Fundamentally software quality issues are organization and people issues. This might sounds a little nasty but what do you think of organizations where the person managing software people is a mechanical engineer, with very little experience, who thinks he should go through all the code base to "understand the state of the code". I would say that's not the kind of organization that produces quality software.

If you want to improve the software quality, invest in your software team. Work on the people- not on the code base. By your own description you're not the kind of person who should be leading the technical aspect, if you can't grow someone in the team to that role then hire someone to help with that.

In terms of your other idea, more automated testing, the answer to that is almost always a yes. But again, get your team there.

OP here. Thank you for the kind remarks. Apologies because I can speak only in generalities; the devil is always in the details. As such this opinion, not prescription.

I read your description as working through a conundrum of priorities, goals, and outcomes.

Perhaps the way is to not get stuck in the weeds of either machines or computers.

What outcome(s) matter for the overall system? What measures make sense in service of achieving those outcomes? How will people get feedback about progress in service of the outcomes?

I am not suggesting some transplanted management framework (OKRs, I'm looking at you). Rather wondering about the small set of things you can get everyone to buy into and work towards. Decision making should become more tractable --- do the magic numbers even matter in the big picture? They may, if you desire to stay within a certain failure rate and/or error bounds, and it turns out the magic numbers are part of the problem. A thing like this won't be obvious in the beginning, you will to investigate things. Being able to say "hey, our stuff is failing at X rate and it is hurting our product/business in A, B, C ways" should help negotiate with management for the time / resource budget. Sometimes it may not be worth it, and so it may be wiser to drop that battle and focus on other outcomes. The investigation ought to be useful later.

I noted Gene Kim's initiative [1] in my post (no affiliation). I feel like that collection of resources will give you much to work with. If you had to pick one of those, I would recommend the Accelerate [2] book.

And, if you wish to talk about any of it, I'm happy to discuss more: https://www.evalapply.org/index.html#standing-invitation

[1] https://itrevolution.com/the-idealcast-podcast/ [2] https://itrevolution.com/product/accelerate/

(edit: expand on the main part of the response)

I think you should probably leverage your team’s experience with the code, and understand what they would prefer.

I don’t have management experience and I don’t know your team, but I suspect if they agree there’s a problem and propose solutions, you’ll have better buy-in, and at least as good odds of successfully addressing the problem.

i find myself in a similar sounding role, i don't have answers for you though. i'm wondering, do you use git for version control and repositories?

Yes, we use Azure DevOps (switched over from Jira). Honestly, I rarely go into it as most of my time is spent developing business and customer engagement.

Reply on news.ycombinator.com