When I first started to program, I went through many phases. At first, I got that IV hit of “Hello, World!” and I felt like a god among men, no longer bound to the same plane of existence of plebs who just use their computer. “Wow is it really this easy? I know what I’m doing.” I thought.
Then things got a little more complex. I started learning about variables, primitive data types, looping, parsing input, and maybe error handling. Quickly I realized just how little I knew. It was daunting, every time I tried to write code...it seemed like I was going through the five stages of depression. If that wasn't enough to intimidate me, I was introduced to things like object-oriented programming...all of it makes sense but you’re not really sure why those things would be THAT helpful, it all gets more confusing. That being said, stick it out, and eventually, there will be a moment where it all clicks, every programmer I know has said they experienced the click or a series of small clicks that cascaded into an understanding of the fundamentals. Unfortunately, after that click, you realize how you know even less than you initially thought.
So, in attempt to save you some time and grief, I have laid out some tips, tricks, and words of wisdom that I wish I had known during my journey to becoming a software engineer. I have laid it out into three stages (There are more stages but I am still a noob):
Greenling: Stage 1
(When you’re just starting to stretch the fingers and learn the basics)
Practice every day.
Understand that you’re not going to be making the next Facebook right off the bat, realistically you’re going to be reversing strings and sorting numbers.
Find someone who can work with you when you get stuck.
Get an introduction book and do the exercises at the end of the chapters. Try to pick books that focus on fundamentals and avoid books that try to introduce you to UI’s.
After you finish the book go back through the exercises and see if you can do it without reading the chapters. Rinse and repeat.
Avoid using IDE’s when possible. It makes your life more difficult but you'll learn more.
Don’t just copy and paste code. Understand what you’re doing. If you don’t understand, ask.
If you ask a question to someone and don’t understand their answer, ask again, change the way you ask the question until you understand their answer.
Don’t start out learning with something like Android or IOS programming. They have fancy features that you’ll just have to accept at face value unless you understand what is going on under the hood.
Start with a verbose language like Java because there is less ambiguity. Everything needs to be explicitly written out. No frills or magic.
Don’t try to sell anyone anything yet, you’ll over promise and under deliver.
You’re going to stay in this stage for about a year.
Beginner/Hobbyist: Stage 2
(You’re competent enough to really screw things up. You can contribute to some open source projects without getting the nerd herd chewing you out. You would be able to get an internship or pass an entry level coding interview)
Practice every day.
Start to do personal projects that can be completed within a week, be realistic.
Don’t be afraid of the command line, it’s vital.
Learn how to use Git.
Try new programming languages.
Learn to RTFM(Read The Fucking Manual) you’d be amazed at what you can learn by just reading the manual.
Stack overflow is an excellent resource but avoids copying and pasting code you don’t understand.
Learn to conform to the coding style of the project(such as { on the same line as the function name vs the next line down)
When contributing to an open-source project realize that people can be very opinionated and will tear you to shreds over a space vs a tab.
Be wary of people who think they know everything and use big confusing terms when trying to explain something simple. If it feels like they are talking down to you, they probably are. Remember that “Algorithm” is just a fancy word for “A step by step solution to a problem in a finite number of steps.” immutable just means non changing.
Feel free to reinvent the wheel just because you can. Rewrite a JSON parser, write your own socket server. Break things.
Try your hardest to understand object-oriented programming. Learn the four pillars. Try to apply them in your personal projects.
Learn how to unit test.
Don’t pick a programming language because it's what you know. Most languages can do almost any task. Learn how to choose the right programming language for the job. Don’t use a drill when you need a hammer.
Expect to stay in this stage for 2 or 3 years.
Enterprise: Stage 3
(You have a job as a developer and can pull your own weight. But remember there is always room to improve)
I called this one enterprise because it sounds fancy. You will quickly find that there are buzzwords being thrown around left and right in the professional world. People are only trying to sound smart or impress management who doesn't know any better.
Learn from your senior team members. Try to take things on that are over your head.
Do not reinvent the wheel at work. Save that for personal projects.
Test your code. Nobody likes to get woken up at 3 AM because your crappy code failed.
Systems in the corporate world are not beautiful, they are all strung together with digital duck tape. You would be horrified to see the code that runs many critical systems.
Never stop learning or you’ll find your skills are out of date.
Only do the 5 things that have the highest value. Throw out all the ideas that aren’t awesome. Don’t do something because you “may need it”.
Follow ubiquitous standards if there are any. Stuff like 3rd normal form for database design and the frameworks design guidelines from Microsoft for C# code. We are not special. We’re not awesome. We need to get advice from people that really are. Go find the best and follow them.
Keep it simple in all that you do. Fight to get rid of all features and have 0 code if you can. If you have 100 lines of code try to make it 50, etc. Build a bicycle, not a space shuttle unless you really need to get to space.
Keep your junk loosely coupled – Don’t have a lot of wide scope state, parameters, etc.
Keep your libraries, classes, and functions cohesive, in short, this means they should do one thing, and one thing well.
If you can’t find ubiquitous standards then follow prior art. Do things like everyone else is doing them.
Understand that there is much more to being a programmer than just writing code. You need to be able to communicate with business partners, gather requirements, come up with flexible solutions for ever-changing requirements.
You will be expected to provide timeframes and estimates (see the last point in this chain) but you will only be right 30% of the time. That’s okay.
When talking to technical people, they understand you are making an educated guess and any timeframe or expected approach is subject to change as more unknowns are discovered.
Unknowns (unknown factors) are normal. If you have to give a timeframe for a project with several unknown factors, don’t be afraid to call them out as you provide a timeframe… then don’t be afraid to push the deadline back when an unknown makes that timeframe unrealistic.
Anyone who tries to take punitive action against you when you extend a timeframe, discussed in A and B, does not understand the technical aspect and is likely unwilling to learn. Avoid having these people as managers or product owners. This is also a great interview question you can ask a prospective employer: “How does your team handle a developer who is unable to meet a deadline?”
This stage is also when you start to figure out what you need to know in order to learn what you don’t know; you are able to pinpoint what you need to learn or know in order to move beyond this stage and into the ranks of the Eternal Neck Beard. You will rarely feel like you know something beyond a shadow of doubt, but your guesses will become more educated.