Not in the way you think it is…
In September of 2018, I began my first of 90 days of software developer bootcamp. I had just recently turned 28 and recent events in my life helped me decide to quit my job (as an e-commerce brand manager) and pivot into being a dev.
My only regret? I wish I had done it sooner.
When I was a kid, I used to think becoming a developer was hard. I thought it required lots and lots of effort to learn. I imagined forcing myself to read technical manuals and documentation. I had visions of studying math and formulas to develop superior thinking skills.
Fortunately, I couldn't be more wrong.
Recently, I reviewed my preconceptions and recognized them as fundamentally flawed thinking. It isn't hard, it shouldn't be complex, and it doesn't require superior mental powers.
I've found 3 requirements to becoming a developer:
- Understand the words and symbols (there are a few of these).
- Understand the grammar (developers call this "syntax" and it's the way words are put together to communicate ideas).
- Understand how to Google what you don't know (so, so important)
Bootcamp
I attended a really interesting bootcamp in Portland, Oregon. What made it interesting wasn't the variety of courses, but rather the first course every program began with.
The first course you did defined every word and symbol fundamental to programming.
Everything from the symbols used in links (URLs), to the fundamental words like "computer" and "developer", as well as deeper technical terms, all were defined.
As I continued through the bootcamp's courses, I began to learn more about the grammar that is used. Fortunately, many languages use a similar grammar (aka syntax) and eventually this becomes second nature.
One of the things the bootcamp stressed was being able to do your own research.
At first sorting out my own confusions was very tough. As I pressed on, I found that using my new vocabulary had a major, positive impact on how I conducted my research.
I began using certain key words and phrases that other developers also used when trying to solve similar problems as me.
At some point, I realized I knew how to Google my coding questions.
Ultimately, what I got from bootcamp was belief in myself.
I knew how to code, I knew how to continue learning and growing, and I knew how to dig myself out of pretty much any confusion.
My First Job
After many hundreds of applications, many phone interviews (and rejections), as well as several coding challenges, I landed my first job as a web developer at an agency in NYC.
The pay wasn't great, the work was challenging, but I loved it.
I was constantly studying and researching because my role as a WordPress developer meant I had a new language to study. Not only that, but I still had so much to learn when it came to fundamentals of web development.
Fortunately, I had all the tools I needed:
- An understanding of common terms and symbols.
- An understanding of the grammar (syntax).
- The ability to research and solve my own problems.
When you have a job, it's so much easier to learn and retain what you've learned.
When programming is your job, by necessity, you must learn new ways to do things.
When you work with other developers, naturally your understanding of development grows. Every developer has a different point of view as far as grammar (syntax), tools to use, and the process (any process) should be started.
Programming is less about repetitively solving the same problem, and more about finding new and better ways to solve the problem.
For example:
- You can start a puzzle by finding all the edges and corners and assembling from there. Or you can start from the main point of interest, and build your way out.
- You can start a video game by discovering what kills you, or you can explore the map, or even by reading the forums.
- You can write a short story from the hero's perspective, from the narrator's perspective, or from a friend's perspective.
As many ways as there are of solving puzzles, video games, and challenges in life, similarly, you will find many ways to code things.
In Summary
So to sum it up, more than a year and a half into my career as a web developer I've recognized a few things that I wish my younger, twenty-something self had known:
- Programming isn't hard, at least not like you might expect. All it requires are good study materials, and enough persistence to keep at it every day, even if it's only for an hour.
- Programming shouldn't be complex, the more I read and study - and I do that daily - the more I find that all senior developers and experts advise us to write simple, human-readable code.
- Programming shouldn't be avoided, just because you don't understand it. It's actually far simpler than it looks. All you have to do is break it down into single, simple components.
If you want to become a software developer or some other sort of specialist, don't become discouraged by how "hard" it all looks, or the appearance of complexity.
More often than not, the complexities are just a result of misunderstanding the words, symbols and grammar.
If you have those fundamentals in, and have some guidance for doing your own research, I believe any subject can be conquered, with a little persistence.
References
If you want to know what bootcamp I went to, or what study materials I recommend, check these out:
- I attended The Tech Academy Bootcamp, they have online and in-person classes and you can find them at learncodinganywhere.com (if you tell them I recommended you I may earn a small commission).
- The Tech Academy also published a tech dictionary with the simplest, best definitions ever. You can find the dictionary on Amazon.
- After completing the bootcamp, I went through most of FreeCodeCamp's curriculum. While they don't cover words and symbols you need to know, they do have a lot of information and best of all, it's free. Learn more at freecodecamp.org
- If you're struggling with computer studies in general, I can't speak highly enough about Study Technology by Applied Scholastics. Here's a quote:
The basic fact is that students fail to learn because no one ever taught them how to learn - that is, how to identify the barriers to learning and how to overcome those barriers.
If you have any questions or feedback, please share your thoughts below.
Top comments (30)
It is like chess, easy to learn, hard to master.
Great analogy Pawel. Every time I think I have worked out an optimum solution to something, I'll revisit my code after several weeks or months and consider:
Anyway, thanks for reading!
Once you mastered, y'll always learn new stuff. That mean, Yoda dont know all stuff ;)
Moving the pieces according to the rules is easy.
But it's hard to compete effectively.
The hardest thing about webdev, is breaking down the problem into logical steps. Small chunks are manageable and easy to build, but the whole project can feel daunting and terrifyingly complex.
Yes agreed! Once you've found that one step which can be solved, the rest tend to fall into place like dominoes.
The easy part is that you can make it hard if you're not paying attention to what you're doing. The hard part is making it easy.
Totally agree with your statement about someone teaching you "how to learn".
I prefer to look at "Is programming hard" like this:
Getting the basics of programming is like learning a foreign language "syntax", "grammer", "parts of speech", are all pretty easy. Answering questions like:
Knowing the correct approach is the hard part and once you have learned it, it seems easy and I suspect you will quickly forget how difficult it was to master.
Your post is heuristic and I appreciate that. Thanks ;)
Haha yes Noel, I fully agree with you! In hindsight, the approach sure doesn't seem too difficult, but at first glance it might appear insurmountable.
Thanks for your kind words.
Programming was never hard. The problems you solve with it are sometimes tough.
The hardest thing about programming is not programming and having to figure out other peoples code.
Yes, but don't you love that challenge? I know I do.
I enjoy reading peoples code. I love PR's. I don't love trying to decide whether it should be completely rewritten or shoehorn in some good code between some bad code.
Ha that's a funny predicament you've brought up. You're making a decision between "is this good code" or "is this code good enough".
This is great advice. Learning to contribute in small bite sized chunks helps to avoid feeling the "burden" of the whole project at hand.
Having a mind for logic and critical thinking helps with speed, but doesn't mean its an inherently limiting factor.
Yes, 100% agreed Alex! And thanks for your kind words.
I would like to say that write code is not that hard, but maintain a code that is always evolving is.
The most complicated part is to avoid doing a mess that slows you, and fix the mess that you or someone else did at the same time that you add new features.
Thanks for sharing your perspective Haruan, and I respect it.
I personally enjoy digging into someone else's code, figuring out what they did and opportunities to refactor. I also enjoy doing that to my own code. It's often challenging to write new code, it's always challenging to refactor someone else's!
That said, I differentiate between "hard" and "challenging". I view challenging tasks as games that require lots of looking, testing, and persistence. I view hard tasks as troublesome which require lots of unpleasant effort.
The difference between those two views is sort of what I was trying to communicate in my article.
Great article and thank you for sharing your experience.
From my experience of learning to program and trying to help others. Everyone can learn to program, but I think the best indicator of whether someone will have a successful and enjoyable career in programming comes down to how they think. If you are able to approach a problem, break it down, and be able to solve that isolated part then moves the next one while keeping the rest of the problem in context then you will probably have a successful career in programming.
I have come to this way off thinking, mostly from seeing many people that have rushed to boot camps because of a career as a programmer will mean jobs with a high salary. Those that normally approach problems in other ways have a much harder time and tend to not want to be part of the constant learning it takes to rise in this field. As a result, they get frustrated with a career they hate just for the money.
Hey Martin, thanks for your kind words, and I respect your perspective.
It's funny, but I always assumed people approached problems in that way (break it down, solve isolated parts, while keeping in mind the whole). Perhaps not everyone does...
If that's not the case, I like to think people can learn newer and better ways of solving problems. I didn't always know how to play chess, but with lots of practice, I got to be pretty good. Chess is one of those games that requires new thinking skills such as being able to see from your opponent's perspective and then predicting his next moves.
I do agree though, there are some folks who don't want to partake in constant learning. And for them, coding might not be the best career option.
Personally, I used to avoid careers which required constant growth (like coding) because I wanted something I could settle into. After finding several jobs with those qualities, I realized that wasn't the right approach. The constant growing and stretching of my mind and capabilities is a heckuva lot more fun than anything else I've seen.
the real motivational nlog for the beginners.....Yes you are right its not as hard as we are expecting it.....The one statement you should highlight that you should break down tasks or components into simple piece of code ..to make it easy and readable.....Learning new framework is tough at the beginning but it becomes so easy when get used to it...
Thanks Nabeel!
That's a great point, and one others have also indicated. It seems we all agree that breaking down large blocks into simple, components one can confront makes for a much better task.