10 Things I Learned From My First Year As A Developer

I recently finished up my first year as a full-time professional developer and it has been an enlightening journey. There are so many things I learned and I wanted to write a few down to reflect. This is highly influenced (of course) by my experience within a nimble custom development shop so your results may vary.
Also this list is no specific order:

_{Sample XSLT Code (You know you love XSLT! :) ) ^}

1) No One Has All The Answers

This was a tough one at first. Being new you assume that the senior guys have all the quick fixes and that they don't even need context for a problem to solve it. They can just glance at it and see the solution. Definitely not true and you even learn there is a healthy dose of "Fake it till you make it." at every level of development.

2) Your Approach to a Problem is Critical

So much time is wasted as you learn the skill of how to approach a problem. 99% of the battle is knowing how to get to the root of your error. You have to learn how to best troubleshoot complex problems and break them down into simpler issues. The ability to isolate something down to the core small errors will save you so much headache.

3) Documentation is NOT Optional

It seems that in the custom software world built by third parties (and maybe this is more common than I know across all development) you create documentation as an after thought. IF it gets created then it is made at the end of the project or maybe quickly at the start without every being updated. So many hours are wasted getting a project up and running for new developers (senior and junior) because of lack of or outdated documentation. I have seen it time and time again.

4) Planning Your Data Model Is More Important Than Your Tools

This is just something that I have seen a few times on projects where the model was not mapped out very well at the start and it just caused issue with the project as it was being built. Thinking through how the data model is going to work helps you discover relationships and data that you might be missing. You need this to be sound and well architected before you ever start to build your application.

5) There Are A Million Ways To Do It

Before you get into the world of development you (or at least I) assumed that commercial software was all built the same and all built very well. I had no idea there was such a thing as an anti-pattern or SOLID principles and a lot of other concepts. Also, I didn't know that you could completely ignore them and build something however you want. You can't assume that because a project codebase you are reviewing or working on is built by a well known company that it is using best practices. There is a lot of bad code out there. There is a lot of great code out there too! Just be aware and research.

6) You Are The End Of The Line

It starts to sink in that all those decisions and user stories that where created stop with you. You are the one making them become a reality and the stake holders want to know how much time it will take you to complete them. At some points it starts to sink in that if this feature is going to exist then you have to make it happen. It is a powerful, humbling and terrifying discovery all in one.

7) Estimation Is A Double Edged Sword

You can't get away from estimating the time a task or project will take you to complete and it comes with so much baggage. The truth I am discovering is that rarely is anyone able to estimate with a large degree of accuracy on tasks or projects they are completing. At first it is pretty intimidating but you learn to balance it because it gives your project managers and stake holders a gauge. Even if the gauge could be busted and partially working, it does provide a reasonable level of understanding on the difficulty of the task. Of course I have also learned that most of the time there are unknowns you discover once you start the task. :)

8) Context Switching Is Your Enemy

My experience with other careers I have had is that they lend themselves to being able to switch between tasks and meetings and ideas very easily. You can drop one and then pick it back up without missing too much or losing much time in most roles. However, in development it is definitely not the case. One of the things I discovered that the more senior level developers know is how to block their time for a task and not allow it to be disrupted until they have completed enough of it to be at a definite stopping point. There is so much time that can be involved with getting a grasp on the context of an issue and then getting the project in a spot where you are familiar with it and the solution you need to perform. Learning to keep that process protected is critical especially in a custom development shop environment where each project could be drastically different.

9) You Don't Have To Know It All

One of the things that held me back at the start was that I felt I needed to reach a certain level before I could consider myself able to contribute to a project or codebase and that is just not the case. I really think that the experienced developers have learned that they need to start moving and breaking down issues into small chunks. They don't think as much about the depth of knowledge they have because they know they will figure it out once they get the issue broken down to the core requirements.

10) It's Not If You Fail But How You Keep Going

I kept looking at other developers commits to repos and seeing solutions and in my mind I was making the jump that they completed that on the first try. I was judging my ability to solve the problem with the code that they committed as if it was the only thing they typed. The real truth is that they could have attempted multiple solutions and this was a refactored version after hours of trying different things. When you are starting out you look at other developers best solution without understanding that they took a road to get there. It takes a while to learn that the strength they have is that they knew how to keep going when things didn't work. The stronger developer is not necessarily the one that knowns more or can solve the issue on the first try but instead is the one that doesn't get blocked. Ultimately no one cares how many times you tried and failed at solving an issue if you ultimately ended up solving it.

---

So here it is. 10 quick things that I feel I have learned over the past year. I am sure if I attempted the list again I might come up with a few different ones. The bottom line is that the experience so far has been amazing and taught me that being a developer is more about how you approach a problem, break it down and keep iterating on solutions until you find one that works. It is less about the amount of languages/frameworks/libs that you know and how eloquent you can make a solution to brag about on twitter.

If you are starting out or thinking about development then I hope this encourages you to see that the rock star developers are just people that didn't give up. Over time they gained knowledge and experience and kept iterating.
You got this! 👍