Ask HN: What decisions pushed you to become a better software engineer? | Hacker News Reader

Ask HN: What decisions pushed you to become a better software engineer?

I graduated with a degree in computer science just over a year ago. I really liked my time in school, but most of it was focussed on theory and my first months as a professional SWE made me realize that I have no idea how to code. I really like the nature of programming, but I find it can be hard to keep up with others at work given the gap between us, so I've been reading and searching for different ideas to help me catch up to speed.

It might sound obvious, but my decision to start my own personal project (a simple database) on the side has really shown me to instinctually try to figure things out for myself, read tools' documentation and ask better questions to others. I've definitely noticed that this helps me when I'm at work.

What were some decisions you made that pushed you to become a better software engineer?

View on HN

Writing tests. I got along years professionally without, employers weren't enforcing it. Over the years I think it made my code better structures, easier work/handover with other engineers, less feat to restructure code and ultimately it saved me from many small and big bugs. It doesn't have to be full coverage, or writing tests before code, any tests are better than none.

this. plus implementing CI as early as possible and getting that working before too much code is written.

Not a "decision" as such, but getting more involved in open source has given me so much, and helped me build skills in:

- Navigating unfamiliar codebases

- Improving technical writing skills

- Keeping abreast of new tool/tech/methodologies/processes

- Maintaining and managing projects

This is a great idea, but its always felt super daunting for me. As in, just walking into a massive code base makes you wonder where to even start. Do you reach out to other contributors ? Look for easy bugs and hope you can keep finding them ?

It is absolutely daunting if you're first getting into a new project, the only thing that helps is experience, and the only way to get that is to keep trying, unfortunately.

Nowadays, I usually contribute out of a somewhat selfish interest in seeing a feature/bugfix get released so I can use it without having to maintain a fork :)

I do indeed try and reach out to contributors by opening a Github issue with comprehensive detail about the change I'd like to make and more importantly, why. Hopefully (and usually) they're responsive, and I can get their feedback and ask more questions, like any particular parts of the codebase I should look at. I also try to look at open source issue discussions/PRs as a process that can takes weeks (if not months), and so it can often be the case that I maintain a fork in the interim period. However, sometimes I just can't wait and am itching to get stuck in, and the best way to do that (without any prior knowledge of the codebase) is to try and trace the execution flow, which is just fancy-talk for adding `console.log(1), console.log(2)` statements in places that seem relevant.

I've certainly heard people say the best way to get started is on "easy" bugs. That may be true to a degree, but for me it was always because I felt a library/tool that I liked and used could be improved in some way. I found it helped me keep up the motivation to finish what I started, as opposed to fixing a random issue from the tracker that I might not fully understand the context of.

When given the opportunity to work on software projects that I was clearly unqualified for, with engineers that were far more talented and smarter than me, I took it.

i decided to learn rust.

Reply on news.ycombinator.com