Dear new developer,
I was at a lunch a few weeks ago and asked some senior engineers and managers what advice they’d give to a new developer. One said: “never stop learning”. I thought this was a perceptive answer and wanted to expand on it. I learn something new every day. I’m going to talk about how to learn and then why people stop learning.
First, how to learn. I think the short answer is “Google”. The internet is an amazing place.
The longer answer is:
- Think about why you want to learn. Is it for fun? To find a better job? To be better at the job you are at now? A side project that you are interested in? Scratching your own itch with a solution? Because you want to make the world a better place? Having a firm “why” will encourage you when things are difficult.
- Determine what you want to learn. From the why comes the what. Is it a business domain? A particular technology? A framework? A certain mindset?
- Consider how you want to learn it. After what and why comes the how. Do you learn best through videos? Reading? Code tutorials? Blogging? A realistic side project? Reading others’ code? Try each of these if you haven’t and see what gets you excited and what seems to cause knowledge to stick.
- Execute. That one little word is hard to do. But you need to find the time and the willpower to take the why, what and how and actually do it. As some say, it’s easy to write and hard to do. Start. And when you fail to make as much progress as you’d like, think about the why.
Why do people stop learning? I think there can be any number of reasons:
- Bored: they simply aren’t interested in learning.
- Frustrated/blocked: they can’t learn what they want to because of other constraints.
- Tired: too much else going on and they need their energy for other things.
- Comfortable: they know what they need to know and are “punching the clock”.
- Shifting priorities: other things in their life have taken precedence.
All of these make sense. And it’s important to realize that you have a job to live your life, you don’t live your life to succeed at your job.
But, if you are not interested in learning new things, pretty soon technology will pass you by. You can still make a great living, but opportunities will get fewer and fewer, and you may need to shift companies or locations, or give up salary. There are definitely people still writing COBOL, but every year fewer companies need it. There may be people still writing java applets, but I can’t think of any companies that need that particular technology.
Another thing to note is that sometimes a shift in perspective, whether a new job or a new way of looking at your current job, can remove some of the obstacles that prevent you from learning.
So, figure out how you want to learn, and never stop doing it.
Dear new developer,
Searching is important to writing and understanding software. Less so for giving you a base of knowledge. For that, I’d seek out books, video classes or side projects, depending on how you learn. Googling well is tough if you don’t know what terms to use. (I’ll use google as a synonym for a generic search. I’ll address issues of other search engines below.) Once you have a firm base of knowledge and understand software jargon, you can stand on the shoulders of giants.
Tips for searching:
- Google the exact error message (almost). When you get an error message like
nginx_1 | 2019/01/06 20:42:22 [crit] 11#11: *1 connect() to unix:/var/run/php5-fpm.sock failed (13: Permission denied), don’t just cut and paste it into the search box. Look at the error message, and see what is unique to your situation. For the error message above, text like the nginx instance name,
nginx_1, and the date and time,
2019/01/06 20:42:22, are unique to my installation. Searching on them won’t be useful. But the message text starting with
connect() looks like it will be far more common and will likely yield good results.
- Read the results, whether forum post or documentation, carefully. I’ve been bitten by this more times than I care to remember. But it’s very easy, when you find a stack overflow, forum or other result that seems to apply, to just cut and paste the top answer as quickly as possible and get back to what you were doing before you started searching. This is the quick path, but the better choice is to read the entire page and make sure that they are addressing the same issue that you are trying to address. You also want to pick the best solution (which may not be the first one, especially if the page is old). Sometimes newer libraries or releases have different paths forward, and so you should try to map the software you are working in to the one that the page refers to. The other reason to scan the entire page is that it will give you a sense of the different solutions. The underlying goal of doing the search is to incorporate the knowledge into your understanding so that you won’t have to do this Google search in the future (you may have to search in your project or commit log, but that’s quicker than redoing a google search, especially months from now). Trying to understand all the solutions and what they are doing is a way to be a just in time learner. Mindlessly copying the solution isn’t.
- Add links to what you find in your commits and your comments. Do this especially if the solution is complicated or esoteric. You should of course write a commit message that explains your intent, but adding in the link can give additional context.
- Think about the terms you use in the query. This is where foundational knowledge comes in. For example, if you know that active record is an object relational mapping tool, or that ruby is a dynamic language where every class can change another (which is called “monkey patching”) then you can know how to google for things related to these concepts. If you want to change a specific active recrod behavior, you might google “how to monkypatch active record” which will get you far more focused results than “how do change the rails database system”. This ca be iterative. Pay attention to the terms used in posts you find, and use them in new queries.
- Consider using an alternate search platform. I use duckduckgo.com as my default search engine. Frankly, it’s not as good as Google, but it gives answers I need in about 75% of the searches, and I can easily run the same search on Google if I need it. I am supporting an alternative search ecosystem that will be better for the internet in the long run.
A last point is important enough that I’m going to break it out. Google, and search engines in general, work well because there’s content out there produced by people. You can take part in producing that content, either by adding to stackoverflow (which can be as simple as just voting an answer up or down–after you’ve tried the solution out), writing a blog post or responding to that forum post. If you encounter an issue no one has ever seen before, write it up, like I did here. This participation in the wider internet is crucial for the continuing useful functioning of the internet. So, participate in some way and give back.
Using Google to solve problems lets you leverage the hive mind for your development work. Don’t just use it. Use it well.
This is a guest blog post from Noel Worden. Enjoy.
Dear new developer,
Don’t be afraid to ask questions. It can be stressful and humbling to reach out and ask a question, but it can be the best way to stop spinning your wheels and make progress. It’s stressful because as a new developer you are trying to prove yourself to your peers and superiors. It’s humbling because you are admitting to someone that you don’t know something. Giving consideration to when and how you ask a question can make for a much smoother interaction.
So, how long should you grind away at a problem before you concede and reach out for assistance? That can be a tough call, and can differ quite a bit based on your situation. Some aspects to consider are:
- Is this meant to be a learning experience?
- If so, you’ll want to spend more time looking for the answer before reaching out to anyone
- How long do you have to complete the task?
- The more time you have before the task is due, the more time you should spend looking for the answer yourself
- How busy is the rest of your team and/or your mentor?
- If no one has the time to help you unfortunately don’t have many options other than to stick it out and try to find the solution yourself until you see an opportunity to ask for help
- Is the sticking point something relatively ‘small’ and holding you up from the bigger task?
- Is it something like a bug in the project setup, or a hangup of a similar nature, that doesn’t have anything directly to do with the task? These types of hangups can be difficult to Google, or solve by experimentation, and are scenarios where asking for help earlier than later is probably a good idea.
- Have you worked through other aspects of the task?
- Sometimes skipping over the sticking point and working on other pieces can lead to an ‘aha moment’.
- It can also help to gather multiple questions and therefore get multiple answers from one help session.
Once you’ve decided to reach out for help, the phrasing of the question can be important. When I ask a question I often try to go over what I’ve already tried, what I’ve Googled, and then what exactly is stumping me. This shows that I’ve made a solid effort to solve it myself, gives the other person as much context as possible, and helps avoid the person giving you assistance to not repeat the same unsuccessful troubleshooting attempts.
Most importantly, above all else, don’t be afraid to ask questions. Everyone was a new developer at one point in their career, and asking questions is a legitimate way to learn.
Noel Worden started his career as a photographer, shifted gears to become a cabinetmaker, then graduated from the coding bootcamp Bloc. He is currently working as a software engineer for MojoTech in Boulder, Colorado.