S3Corp. Tech Blog

The programming community is often praised for how everyone helps each other out. At Codementor, an online platform with 3000+ expert developers who can provide users 1:1 programming mentorship, we are able to reach out to senior developers/engineers who work at companies such as Facebook and Amazon to host free, live Q&A sessions on our site, where you can ask them anything from career advice, opinions, and more.

Perhaps you’re an aspiring software developer/engineer unsure of whether you’re on the right path, or maybe you’re a newbie eager for guidance from someone experienced. This article is a summary of various tips and advice seasoned devs have to share with beginners to programming.

Without further ado, let’s get into what the developer community wants you to know!

Tip #1: Practice!

You won’t get anywhere if you just sit on your ass and lament that you suck at coding. Asides from following tutorials, you should work on your own projects.

“The most fundamental thing is that you actually go and code,” says Andrei Thorp from Evernote. “I’ve heard it recommended that by the time you finish college, you should have written 100,000 lines at minimum.”

But how to get started, you may ask.

“I always tell people to find something they’re doing more than once a week and to try to automate it. Ignore if anyone else has solved the problem before, and just make a tool/utility for yourself that fixes a common issue in your life,” says Kasra Rahjerdi, who’s the Mobile Lead at Stack Overflow.

“Like any other skill, it takes practice – deliberate practice, stepping outside of your comfort zone and learning the nuance and subtleties – that set apart great from good,” says Derick Bailey, the creator of WatchMeCode.net. Derick is a top 0.42% StackOverflow user, and has also contributed to open source frameworks such as has MarionetteJS and BackboneJS.

It’s OK to fail. Coding is all about failing and fixing things, and about learning how to do things better. If you don’t build things and work on areas that you know you are weak on, you’ll never get better.

If you ever need to receive advice on how to improve and what you’re not doing so well on, feel free to ask an experienced developer to help your get straightened up by either reviewing your code or walking you through concepts you are having trouble understanding.

Tip #2: Be Patient

No-brainer here, but beginners often wind up frustrated by their lack of progress and forget that they’re not alone.

“Becoming a good programmer takes a long, long time and a lot of tedious evenings,” says Mike Arpaia, a former Etsy dev who now builds information security software for Facebook. Mike stresses that beginners should give up on the assumption that one can become an excellent developer quickly. “Before you can write good code, you have to write hundreds of thousands of lines.”

But… What if you’re not even past the tutorial stages yet? What if you’re still banging your head against the wall and wondering perhaps you’re just not cut out for programming? Before you leap to conclusions, know that everyone has a different learning style. Author of the Ruby on Rails Tutorial, Michael Hartl, points out that beginners should try lots of different resources (books, videos, etc.) to see what ‘clicks’.

In fact, Craig Coffman, the CTO of Reserve, has personally learned through a lot of trial-and-error and by picking projects that were personal and interesting. However, since all the interesting challenges are big ones, he suggests beginners to start with biting off reasonably-sized pieces. “That way, when you lose interest or get stuck, you still have a feeling of progress and accomplishment.”

Tip #3: Stay interested

If you’re bored by the project you’re working on, you should probably reconsider any lofty goals of learning to code. Or, maybe you’re just working on the wrong project or learning through the wrong resource.

Always keep yourself motivated through working on personal projects that excites you.

Coraline Ada Ehmke, founder of LGBTech and contributor to high-profile open source projects such as Rails and RSpec, started coding at a young age out of interest. However, her first class in college as a Computer Science major made her doubt her passion. “I remember our semester-long project was to write software for an ATM. I was so bored and not challenged, I decided that if that’s what life as an engineer was like, I didn’t want any part of it, so I dropped out soon after.” However, she continued to work on projects she found interesting. By 1993 she was online and building web sites, and has been developing web apps ever since.

For more tips on how to stay motivated, feel free to check out the 7 secrets to staying motivated when learning to code!

Tip #4: Love the Error

As a beginner you’ll likely be mired in bugs. If you feel intimidated by all the red, you’re not alone. Ross Chapman, a UX Engineer who coded for Zendesk and now works at ScienceExchange, admits to being a scared developer when he first started out. “I didn’t have the patience because I wasn’t ready to love the challenge of fixing things. But that’s pretty much where all my really bad habits come from.” With that said, Ross urges beginners to embrace errors as crucial learning moments.

Since you’ll be debugging for life, you should get used to errors and learn to recognize the error messages. “Being able to quickly parse and understand error messages will save you a lot of time and get you a long way,” says Jack Franklin, author of “Beginning jQuery”. Jack also recommends beginners to make an attempt at fixing problems on their own at first. “The fact you’ve tried will be very much appreciated by the person you’re asking for help.”

When hitting a wall when debugging, Lee Byron, co-contributor to Facebook’s React, personally attempts to understand what’s going on by making ample usage of the debugger tools. “Once I understand exactly what is happening – step by step, then I can compare that to what I expected to happen and isolate the surprising parts and see where my assumptions were wrong or how some code led to the surprising situation.” Errors aren’t limited to bugs, however. Sometimes, you make bad decisions such as using the wrong data structure. According to Mike, getting burned by those bad decisions will eventually help you learn when it’s reasonable to use certain design patterns.

Tip #5: Understand How things Work

“No matter what level you’re at I’ll say this: never ever write a line of code without knowing why it works, to the metal. Like, be obsessively curious. Be the Indiana Jones of source. Curiosity is one constant among engineers. I don’t think you could make it in this biz without looking into the monitor with wonder. Both childlike, and ruthlessly academic.”
~ Ross Chapman.

Suffice to say, interest is not enough. You have to strive to understand how things work if you’re aiming to become a professional developer of some decency.

You can start out understanding the tools you use by sifting through StackOverflow questions. “I’ve learned a thing or two from them,” says Todd Motto, who’s an AngularJS conference speaker and Developer Expert at Google. “[The top AngularJS questions are] really interesting to read through as Angular is such a big framework.”

Rohan Singh, a senior infrastructure engineer at Spotify, stresses the importance of working towards understanding the layer one level of the stack beneath what you’re working on right now. “Everything we do as software engineers involves working at some level of abstraction,” Rohan says. In other words, if you use some sort of database, you can take away the internals of the database and expect it to “just work”.

Furthermore, to really understand how things work, you should be able to explain why certain technical choices are better than others, and be able to troubleshoot problems when things don’t work the way the do. Rohan achieves this in practice by trying, a little bit at a time, to learn about and understand the fundamentals of whatever platform or system he uses — whether that’s Python or Go or the Linux operating system. According to him, this eventually helps you generate a mental of model of how things work under the covers, and broadens your base of understanding.

Ultimately, you’ll grow as engineer, and as a bonus you’d be able to debug more efficiently by learning how to do more “lean back” debugging as opposed to “lean in” debugging. In other words, you’d lean back and think hard about how things work under the covers to figure out what the problem might be. “This can be a lot faster and involve a lot less flailing than ‘lean in’ debugging with an interactive debugger or other tools,” Rohan says.

In fact, Andrei Thorp from Evernote thinks everyone should learn basic C early on. “Because it’s minimal and doesn’t do much for you, it forces you to understand how computers really work on a lower level. For example, C makes you manage the memory you use yourself – which means that later, when you use something like Python, you actually understand what Python is doing for you. Then, when you see some strange bug, you have this toolkit in your mind to understand what the problem could be.”

Tip #6: Keep Learning New Things

”Nothing will kill your career/craft trajectory more than working at some shitty mundane programming job,” says Jonathan Henson, who currently works at Amazon Web Services. “Go somewhere where you are encouraged/forced to constantly learn new tricks.” Jonathan also tries to learn a new programming language, paradigm, or stack every year. He then puts himself on projects where he would have the opportunity to apply those skills.

“I think the most important skill to learn is meta-learning,” says Kasra. “That’s what separates engineers and programmers to me. There’s something to be said about spending 12 weeks at a course learning one framework really well, but I really respect (and like to hire) devs that are able to learn whatever they need, on the spot, to do a task.”

So, what’s the best way to learn new skills?

Reading about what you want to do is a start. Steve Klabnik, who’s a Rust core team member and ranked #37 on the all-time Rails contributors list, seeks out any established research on the topic and also tries to figure out how people who are good at the thing he wants to do achieve their results. “The most important thing is to just do it,” he says. His personal approach? “1. Try to do the thing, probably do it poorly. 2. Figure out where I’m going wrong, and what i need to improve 3. Work on what I’ve identified. 4. Repeat.”

CTO of Bellhops, Adam Haney, says his favorite trick to learning new languages is to reimplement a previous project using the paradigms of that new language. For example, he would take something he wrote as object oriented code in C++ and then reimplement it in a functional language. “I feel like this kind practice has prepared me to evaluate new technologies because I understand the underlying Computer Science principles even if I don’t know the intricate details of the language or framework.”

If you struggle with memorization, Andrei recommends building a memory palace. The general idea is that you use your brain’s powerful visual memory, and map that to more technical data, like numbers. He also strongly believe in techniques like The Seinfeld Calendar, which is based on Jerry Seinfeld’s idea that you don’t need to work hard every day — you only need to progress a little bit every day. “So with his calendar, you just check off whether you worked on the project today or not,” Andrei says. “There are some nice apps that will help you with this. On Android, I use HabitBull. As your streak gets longer, you feel more motivated to keep it running!”

Tip #7: Learn How to Work with Others

Another way you can learn new things is to work on projects with other people.

“The legend of the lone coder is a myth,” Adam says. “Almost all substantial projects require teamwork.” This means you’ll need to learn the skills of breaking a problem down into multiple parts, build good interfaces between parts of the codebase, and collaborate on architecture.

“Working with a group of like-minded engineers who challenge you will definitely put you on the fast-track,” Craig says. “Working in isolation makes it hard to catch yourself making silly choices and to learn new things.”

Everyone makes mistakes – that’s just how programming is. Beginners should strive to hang around great engineers and receive feedback. “Don’t be sensitive about your mistakes,” Jonathan stresses. “That’s how you improve. Admit your mistakes and learn from them.”

Getting your code reviewed will also force you into thinking about why you did something and understand code better. “My favorite engineers to work with are the ones who don’t let you off the hook about the code you write,” says Ross. “I remember when I first was challenged, and it freaked the shit out of me. But that night I went home and studied till I knew I could at least attempt a confident explanation of how to pass this around closures.”

So, where do you find mentors or peers who can pair up with you and help you out?

According to Jack, local meetups often have sessions where free coaching is offered to anyone who would like it. Other free resources include Twitter groups, Slack groups, and iRC channels.

If you’re fine with spending some money to get your code reviewed by an expert, you can get help from a Codementor.

Tip #8: Don’t Just Code – Build Solutions

“A lot of programming isn’t about code, it’s about understanding other disciplines or standards,” Adam says. “You can’t solve someone’s problem with code if you don’t understand their problem. Working on projects exposed me to the way that small businesses, marketers, brokers and other professionals approach the world. When you understand how they currently solve problems, you can work with them to come up with new and better solutions.”

One thing Ross wish he had done earlier in his career was to better appreciate the discipline and history of Software Engineering itself.

“These days it’s easy to dive into the vocation and only focus on the “coding.” Especially as browser coders or web app coders in a booming market working with huge dynamic programming languages (Ruby, JavaScript) and vastly quirky “computer” languages and formats (HTML, CSS), we might be tempted to spend all our time racing to master the myriad tools, frameworks and APIs so we can crush interviews or level up at the job. But building a product on a team is always a social exercise, and a particular one at that with a unique set of challenges that are mostly non-technical. Like, turns out the hardest thing in software engineering is deciding what to build, not how; though maybe this is less true in as the JavaScript mycelium rhizomes dramatically.”

Ross said it took him a while to understand that most of software engineering happens in your head first. “Coding will likely become the easy part soon. But a dope engineer can draw a solution with boxes, circles, and lines—and I know that’s a learned skill because I’ve been doing it more and it I’m getting better at it.” The realization that coding was much more “chin in hand and white boarding” was actually so resonant for him, he wrote a blog post about it.

“Remember that this is about human beings and our lives, not just about the technology that you’re coding with,” says Derick. “Learn how humans think, interact and deal with each other. Then represent what you’ve learned in your software development architecture and design.”

Tip #9: Don’t Re-invent the Wheel

Finally, no matter how good you get, your code will never be 100% original, as many problems have been solved in your language of choice already. “Absolutely ain’t no shame in keeping the wheel as is,” Ross assures. “However, when it’s time to commit, you better be damn sure you can defend that code to your team with Dwayne Johnson-like charm and confidence.”

“Don’t re-invent the wheel just because you don’t understand an abstraction,” Mike reminds us.

However, this isn’t to say there is absolutely no value to re-inventing the wheel. Matthew Zeiler, CEO of Clarifai, encourages people to build things that already have existing solutions if that’s what interests them. Building a tool from scratch will help you learn more about software engineering, system design, scalability, and more.

Software Engineer vs Developer: What’s the Difference?

After reading this article, you might be curious or confused about what the difference between software engineers and developers are, since many of the experts quoted above have the title of “software engineer”.

Ignoring the disorganized and seemingly random job titles that practically bundle these titles up into meaning the same thing/function, if you really want to differentiate the terms, here are the commonly associated definitions:

Programmers just turn clearly defined solutions into code, and all beginners start out with the aim to become a programmer. As the saying goes: everyone can become a programmer.

Developers take this further – they can code and design solutions and mostly focus on solving real-world problems. All developers are programmers, but not all programmers are developers.

Software engineers, on the other hand, see the big picture and have a deep understanding of how code and programming languages work, so they specialize in designing good solutions that are scalable. In general, the title “software engineer” is often viewed as more prestigious than “software developer”.

Perhaps one should trace the reason for this difference to how things were traditionally. Back in the days when the web was still in its infancy, software “engineering” was commonly associated with desktop applications that solved complex issues, while web application development were people who built relatively simplistic websites.

However, thanks to technology’s recent advances where almost everything is getting moved to the web in one way or another, the line between web developer and software engineer is no longer so clear. Most complex problems are now being solved through web technologies. If you take a look at the job titles on large tech companies like Google, Amazon, or Facebook – web developers often aren’t even called web developers anymore. They’re called software (development) engineers, even if they’re essentially working on web technologies.

Suffice to say, all software engineers are developers, but not all developers are software engineers.

So, with that in mind, instead of obsessing over software engineer vs web developer salaries or whether you should become a software engineer or developer, perhaps it would be more practical to think about your goals or what you find more important or interesting.

That is, if you’re aiming to take higher level positions or work at big tech companies,  you definitely should have the mindset that is commonly associated with that of a software engineer.

Conclusion

Frustrations abound when learning how to develop apps or projects, but hopefully the tips above made you feel more confident in your quest to become a developer. Perhaps getting down to the bare metal of programming isn’t your thing, and maybe that’s all right. However, as mentioned in this article comparing a good developer vs bad developer, one should always strive to become a better developer, so make sure you don’t become that dreaded bad developer everyone else on your team will want to strangle!

Source: https://www.codementor.io