7 essential tips for the developing developer!

#beginners #sideprojects

7 tips on how to become a better software engineer

So you fancy yourself a software engineer? Maybe you've built an app, graduated with a degree, or heck maybe you have been working in the field a number of years. You feel like you have made to the end of the road. Well I hate to break it to you, but that road is just beginning!

It's easy to be a software engineer but much hardware learning how to be a GOOD software engineer!

If the above statement applies to you, I can assure you that you are not alone. Early on in my career as a software engineer I felt the same way. "The hard work was done and now I could go out and find a job". From that point on I would learn everything I needed to know while making fat stacks of cash!

That isn't what happened to me and it probably isn't going to happen to you. In my experience, while the company you work for might have good intentions, they are likely not going to be effective at fostering an environment where you can stay up to date with current software engineering practices. In addition over time as you start to learn the code base, the types of work you will find yourself doing is likely going to cause you to stagnate in things that aren't specific to your current position. I don't care how good you are at your current engineering role, you are likely on slow walk to getting really good at working for the company you are employed with, while losing touch with the current developments and frameworks.

If you don't believe me ask yourself a few simple questions.

What version of your preferred language are you using?
Is it the latest version?
What are some of the differences between the version you are on and the most current version?
What version of .net framework are you using? How many versions have been released between that one and the current? How many breaking changes have been circulated between them?

These questions will likely go a long way toward showing you just how far behind you are on just the baseline stuff. This says nothing about open source and supporting frameworks, new development styles, new development tools and all of the other wonderful stuff that is constantly changing in the software engineering world.

I used to think that these things didn't matter.

It didn't matter to me that I was developing on Visual Studio 2013 instead of Visual Studio 2019.

I didn't realize that all those things that I saw in job postings we ACTUALLY big gaping holes in my knowledge. These things are important to hiring managers (I'd done some work in ASP.net. That's close enough right?). But once I started finding the avenues to easily start learning these things it really opened my eyes as to the sheer volume of information that I was missing just because I wasn't working on my craft outside of work.

So what should we do to become a better software engineer?

Start listening to Podcasts.
Podcasts huh? If you'd have told me 5 years ago that I'd be here today recommending that someone else , or even that I myself would become a regular podcast listener. I would not have believed you. But here is the thing with podcasts, if you can find a few good podcasts tailored to your industry and listen to a few episodes a month on your commute or some other designated alone time, you can find yourself with a ton of great "pointers to things for yourself to learn and explore later when you have focused time to study" What I find is that when I am working on a training course, these courses tend to focus on the small details, and often I find myself having memorized a set of instructions which I might be able to repeat later but with a tenuous grasp on the higher level stuff. It's almost like I have a pocket full of arrays of data when I was hoping to have a neatly organized jagged array of new cool things I learned. I think it takes a mix of these two elements to really learn something and this is where the podcasts come in, while you are doing essentially nothing you can start priming yourself for what you need to learn and then taking that learning to a higher level. This really helps to hone in on where your attention needs to be while studying the details. If time is money then this is free money!
Get an Audible account.
Ok so you have bought in on the podcasts idea and you've started to learn how to learn passively, now it's time to take it up a level! Get an Audible account! Audible is a service by amazon which costs $9.99 a month and allows you to choose ANY audio book in the library each month. You are awared 1 credit a month to purchase a book and after your purchase it you own it. Podcasts are great for absorbing general discussions about things you want to learn about, but they don't always have more specific informationThey often don't go into detail about the topics discussed. For that reason, I suggest you get an Audible account and start amassing a collection of technical material. The $9.99 a month cover charge for Audible is a great investment!
Get a PluralSight account.
(Or another service that provides the same thing) PluralSight is a video training sight with a wealth of video course that can teach you about just about anything in the technical field. Get a PluralSight account and designate some time to work through a course or at least a few sections of whatever it is you have decided is important for your professional development. I have likely learned more from PluralSight than I have from the bulk of the college courses I have taken.
Start looking for Meetups around you.
Meetups! Meetups are local groups, usually dedicated to specific technical disciplines that that allow you to sit down for a period of time and talk shop with your peers. Even if you are working consistently with peers at your day time job you likely aren't replicating this experience. As a bonus meetups allow you to extend your professional network which is going to make finding a job and gaining new perspectives much easier in the future.
Force yourself to practice.
Practice , practice and more practice. If you want to be good at something you have to make yourself practice. I recommend making a goal to practice programming every day. This isn't always fun and it is easy to fool yourself into thinking that it is not necessary. It's easy to convince yourself after spending all day working on code, it isn't reasonable to come home and work on more code. My advice here is to look ahead to projects or responsibilities that you expect to tackle your current job. (or your future job) Use PluralSight to target courses that teach you NEW ways to tackle these projects! Start working on classes that prepare you for your immediate future as a developer. Complete the work, become good at it , and then go pitch your solution as THE solution for the upcoming problem. This helps you to stand out to your peers and your boss! Go get that money guys!
Constantly look at job postings
Even if you aren't looking for a job (and you should be always) start looking at postings. Looking at job postings give you an idea of what skills you are missing should a time come that you NEED to find a job, using all of the aforementioned tips on how to self study, if you are doing them right, you are less likely to find yourself in the oh too familiar situation of looking for a job but only having experience in half of the common concepts and frameworks that are currently in demand. Also, don't fool yourself into thinking that these requirements are beneath you , or the skills you have already learned make up for not having them or even that due to your vast experience a hiring manager will choose you instead of a candidate that already has them. That is self sabotage at it's best!
Refactoring is your friend. Do not settle for your first solution.
Lastly learn to love to refactor your code. Do it once, make it pretty and then refactor it again. keep a list of items you want to improve while you are building your code and then do them when you have time. I can't stress enough how important it is to be able to critique your own methods or how much you learn from rewriting your code and chipping away are assumptions while you implement best practices.