DEV Community

Emmanuil B.
Emmanuil B.

Posted on

What I Learned From 1 Year as a Software Developer

It has been over a year since I've started my first professional developer role and to say I've learnt a lot would be an understatement.

I wanted to share my personal writeup of some of the lessons, both technical and work life, that I've learnt.


Don't be afraid of challenging tasks.

It's easy to be intimidated by large, challenging tasks, especially if you feel you arn't ready for them.
However, I found that these kinds of tasks are the best, quickest way to learn.

For me, a task that you don't have an immediate answer to are the best kinds of tasks.
The process of researching and figuring things out is why I enjoy programming.

Learn things as they come up.

You can spend an infinite time learning, so don't learn everything possible before starting to develop something.
Learning to get something done, and then learning improvements and filling in knowledge gaps seems more productive.
On top of this, manually trying is a greater way of internalising the idea than only reading or watching a video.

True power of tests (and typescript).

Having not worked on a large enough project before this first professional role, I have never had a satisfying internalisation of why one should use a bunch of tests.
Of course I knew that the core idea is to check whether your code worked or not, but this never seemed too important (why would you write broken code?).
I was missing the key experience of working on a large, continuously evolving codebase.
Once a codebase stops being static, tools like tests become almost essential.

This is because tests provide the confidence to make possible large scale refactoring.
When refactoring, you need to keep the end behaviour the same, which is hard to do if you have no way of knowing if the end behaviour is in fact the same as before.
As you might expect, larger scale refactoring has large scale ramifications.
Making sure the behaviour stays with the same would be very hard if testing manually.

That is the main idea that helped me understand testing.
Some other ones are:

  • When not working on an area for a while, tests, along with function names and so on, help me remember the specification.
  • There have been times where a tiny oversight or use case that I would never have thought about caused a test failure.
  • Having a steam of green text when running tests is very satisfying.

Read high level dev articles.

By high level, I mean stuff from senior people writing very long, in-depth articles about a particular topic.
These kinds of articles explore a large part of the information space for a given topic, allowing you to see the bigger picture and significantly increasing the efficiency of learning.

When building a feature, keep the future in mind.

Try to account for possible future updates, though not too much, so as to not overbuild.
This has helped me many times, as I don't need to do as much work when building future features, or completely change the way something is implemented to account for the new feature.

Learning is exponential.

A great thing about learning is that it becomes easier the more you learn.
Once you learn something, that understanding allows you to grasp related topics much faster, since it will likely share similarities.

An example is programming languages.
Learning my first language was so much harder than my latest, and it's precisely because similarities mean that everything is not learnt from scratch (even in the case of completely different programming paradigms (e.g., imperative vs functional), there are similarities).

Understanding people (clients) is very important.

As I work independently for a client, I get the raw, non-technical specification.
Understanding that spec and turning it into code is a skill in and of itself.
Having strong communication skills, being able to ask good questions, the ability to explain technical limitations in an understandable manner, all very helpful skills.

Bonus:

Learn some keyboard shortcuts for your IDE.

You don't have to learn Vim, but even a few keyboard shortcuts can dramatically increase your productivity.
For example, for VS Code, Ctrl+P is amazing for quickly finding files.


If you enjoyed this article, please consider sharing it.
Checkout my github and other articles.

Top comments (2)

Collapse
 
yuridevat profile image
Julia 👩🏻‍💻 GDE

Nice article and great insights. I can relate to all of them.

Many great years are yet to come 🙌

Collapse
 
emmanuilsb profile image
Emmanuil B.

Thanks a lot!