
Ask HN: What decisions pushed you to become a better software engineer? - chrisandchips
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&#x27;ve been reading and searching for different ideas to help me catch up to speed.<p>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&#x27; documentation and ask better questions to others. I&#x27;ve definitely noticed that this helps me when I&#x27;m at work.<p>What were some decisions you made that pushed you to become a better software engineer?
======
mtmail
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.

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

------
niteshade
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

~~~
chrisandchips
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 ?

~~~
niteshade
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.

------
cmollis
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.

------
bradwood
i decided to learn rust.

