Skip to content

What they don't teach you in college: What I learned during my first year as a software engineer

What I wish I had learned in college.

2 min read
What they don't teach you in college: What I learned during my first year as a software engineer


I've learned to do the following as a junior software engineer during my first year in industry.


  • Write a design document
  • Document as much as possible
  • Test-Driven Development but not 100% test coverage
  • Log as much as possible

1.) I learned to start with a design document

A design document is a way of showing viewers of your software what the intended behavior is. I like to use an open-source online piece of software that allows you to save the drawing to your local machine. So, what I like to do is layout the program's intended logic is with all the possible decision paths, which has helped to find edge cases and write tests.

2.) I learned to document in several different places and formats

At first, I only documented with comments and code, which I quickly found was not enough because of readers of my code were from many different backgrounds and were not always DevOps engineers like me.

I create the following for each new feature:

3.) I learned to use Test-Driven Development for faster bug-fixes and also for documentation

Test-Driven Development is the idea of writing tests first before writing out the code. I've found that drawing out the logic of the program with helps to come up with the tests.

There have been several times that other developers have found a bug with my feature and been able to submit fixes quickly because of the tests helping them to see what the intended behavior is of the program(s).

The same has happened to me while needing to put out a patch for a bug affecting production.

But, something that is important is to keep in mind why you're testings things otherwise, it can become all too easy to become consumed with test coverage percentage and not on purpose, which will lead to a waste of time in writing tests that aren't necessary.

4.) I learned to keep a log of all the work I do

A log of work is great for several reasons. First, it serves to quantify what you are doing daily, and secondly, it helps to focus on what needs to get done. So, what I've done is set up a simple markdown log like so:

# folder layout 

How each day is formatted

DAY 11

- Close out ticket from yesterday


- [ ] meeting
- [ ] feature
	- [ ] something that the feature needs
	- [ ] infrastructure for the feature

[ ] foo
[ ] bar
[ ] boop
[ ] Open Ticket

Logging has been helpful in keeping with everything, especially the little things that like replying to that one e-mail or rotating that one secret for that one thing.


I hope incorporating a few of the above into your work routine can help you with your daily tasks whatever they may be.



I'm DevOps Engineer by Day and an Indie Hacker by night at I like to share what I'm learning in both my professional work and my Indie Hacker projects. Find me @_toul_ on twitter.