What I’ve Learned In A Year As A Developer
EGO
Not to toot my own horn here but when I completed my coding bootcamp, I didn’t think creating my personal projects were difficult. I quickly discovered that completing the bootcamp did not inherently mean that I was a great developer. What it meant was that I learned to learn computer science fundamentals.
One of the things that every engineer will tell you is that you are constantly learning things, so it’s really important to understand your learning style. Personally, I tend to work best from video tutorials and then implementing what I learned in a separate environment. If I can’t find what I’m looking for I refer to the docs. I’m not ashamed to say that referring to the docs is secondary for me because reading a tutorial for me has always been difficult. It reminds me of reading about thermodynamics and watching videos on thermodynamics. For a visual person like myself it can make a huge difference.
With that being said, I was confident going into this field expecting to be miles ahead of people because I built small projects. Little did I know that working in a bigger code base would cause me to take a much more humble approach to this field.
I’m never afraid to say that I don’t know something because honestly, no one in this field knows everything so it’s okay. Don’t be afraid to ask question but find a good medium between googling your questions and asking your team. You’ll know if you should reach out to your team when your question seems so specific to you that you probably won’t find it on stack overflow.
Incremental Improvements
You ever create the UI and logic for a feature only to miss a couple of test cases and the mobile view? That happens. Whenever I’m handed a design I work on the UI and then I work on the logic. It always seemed so intuitive to do it this way but as a junior with minimal experience building mobile screens, I completely dismissed mobile design. Now it’s one of the things I touch before moving on to the logic of my feature.
Unfortunately, as we make changes to the design and rework the logic, some of the mobile design may get skewed. The improvements come in considering mobile view and giving it the time and attention that it needs. I’m not claiming to be the best at it but we’ve come a long way from day one.
The other thing is noticing what you miss and using common sense for some designs. Whenever I got feedback form QA, I would notice some things that were consistent with the current project and the previous.
This text should have an ellipsis.
This input should not allow negative numbers
The placeholder should disappear on focus
In an effort to be a better dev, take notes of those things that you frequently miss and keep those in mind. Add those things to your developing flow so that it’s one less thing to worry about.
Dev Velocity
I’ll be honest on this one; gauging my dev velocity is still an incredibly difficult task. Most of my features get done within a two week span. That will always depend on the size of the feature but I notice that anything that requires creating or editing something in the database will put me in the two weeks ball park.
I’m not sure how important it is to track that for yourself but I will say that its something to consider when meeting deadlines. I currently don’t have any hard deadlines with my team but I create my own by telling them my estimated time of completion. This really helps in honoring my word and if I don’t meet that deadline be honest and explain what the hold up is.
New Techs
Coming into this role, I was experienced with Javascript, React, and Ruby. I taught myself Node.js and picked up a Cloud Practitioner Certificate to try and level out the playing field. Unfortunately, I wasn’t experienced at all with Redux for state management so I immediately went into panic mode. It was the same feeling as getting a trick question in a quiz and feeling like you’re missing out on some crucial information.
Luckily redux is still javascript so it wasn’t like I had to learn a new language but you learn soon enough that it’s part of the job. My friends that are software engineers have had to learn new languages for new roles plenty of times. They tell me that it’s not too bad. You pretty much know what you want to do. All you need to learn is syntax. It’s not like you’re learning how to code all over again.
Imposter Syndrome and Performance Anxiety
When I was in my bootcamp, coding in front of my peers never seemed embarrassing. Probably because I understood that we were all on the same page, but when I started to interview I would freeze up. Almost like everything that I had learned went out the door. I’m still trying to figure out what exactly that is but its been an issue for me.
This doesn’t only apply to interviews but also when I’m pair programming. When I share my code and make adjustments in front of my tech lead, I freeze up. I forget the names of my variables, I forget what props I’ve sent down, I forget why exactly I did something the way I did it. I don’t have a remedy for it yet but I have a game plan that similar to exposure therapy.
If I desensitize myself to that kind of environment it’ll hopefully allow me to clear my head and focus. At this point, all I can think about when someone is watching me code is how they’re watching me code. This is still a work in progress.
Conclusion
Make a list of all the features and projects you’ve worked on. In a year you’ll be surprised to see how much you’ve actually learned. Note the progress that you see in how readable your code has become, the time it takes to do certain things, and trying your best to make your code unbreakable. For those things that induce imposter syndrome or performance anxiety find the cause of it all. Just remember incremental progress is key.
Thanks for reading!
