| Hi HN, I'm about 3 years into my career as a Software Developer. I've realized my day to day has almost nothing to do with architecture or programming. It is mostly about problem solving with constraints--creative solutions to bespoke problems (not programming problems). For example, we had a feature that streamed one of our large models to prevent Out Of Memory exceptions, but it was extremely expensive. The goal was to reduce the cost of this feature while maintaining reliability in the service, so no Out Of Memory exceptions. We ended up turning off the feature, deploying a larger machine, which fixed the Out Of Memory exception for most cases, and if it still failed, only then do we initiate the streaming of the resource. I would've never thought of this. My initial plan was to root cause the high memory, which might've been a rabbit hole even if timeboxed, and I don't think I would've had a solution at the end. I suppose I was trying to "fix the high memory issue" instead of "reducing cost", which was what I was actually tasked with doing. My take-a-aways were:
1. If it can be solved with more money, it saves you time.
2. To prove something is or isn't necessary, run an experiment. I think these are lessons I can learn over time but I'd like to actively work on it. I've heard these can help:
1. Solve lots of problems (where do I find these kinds of problems?)
2. Read post-mortems
3. Read editorials
4. Read about different architectures Or is it something that just comes with experience? Thanks for the help! |
2. You can solve lots of problems and it might help. Over the course of time, my problem-solving skills improved slightly by the amount of problems I was solving. My problem-solving skills improved a lot just by polishing my problem-solving method. At the start of anything I take 15-30 minutes to write down the tasks I need to do and coordinate with others to check if it's the right set of things. I write, down to the classes, that I think I need to work on. For debugging, it's polishing the red-green-refactor cycle, for harder bugs I write the actual layers I need to peel (os/db/language version? database layer all good? weird logs? check disk? check I/O? network? skim through mailing lists? iperf? database? etc.).