Dear new developer,
Think about the edge cases.
This is one of the primary ways you can add value. Think about what happens when things go wrong. It’s usually relatively straightforward to consider the happy path. Let’s take the example of a relatively simple ordering application. People can login, see their orders, and can change certain aspects of their orders (their address, perhaps) before a product is shipped.
Begging the question of why aren’t you using an open source solution like Magento or a off the shelf saas solution like Shopify, there are other things to be aware of.
- What happens if the user wants to ship some orders to one address and some to another?
- What does the user see when they login but have no orders?
- What happens when they change their address?
- What kind of validation is needed?
- How do we know when a product is shipped? What do we do if a user wants to change their address but the product has shipped?
These are all edge cases around the happy path of login -> change address -> exit. But they are all going to affect the user experience, and so are worth thinking about.
I prefer to do it at the spec time, but any time to ask these questions is a good one. Otherwise, you’re either going to have:
- the edge cases pop up and be handled poorly,
- or developers making up the answers while coding
So, new developer, when you get a change to talk about a feature, think about the happy path, the expected path, to be sure. But also think about how things could go wrong.
Dear new developer,
This post talks about how to ask for mentoring, but the principles apply to getting in touch with any busy person. Busy people are by definition busy, and get a large number of emails and requests every day. (Here’s a VC talking about the difference between ignoring and not replying, and how they look the same to a sender.)
The key is that you as the requester need to put in some effort. From the post:
In other words, when you asks for a busy person’s time for “mentorship” or “advice” or whatever, show (a) you are serious and have gone as far as you can by yourself (b) have taken concrete steps to address whatever your needs are and (optionally. but especially with code related efforts)(c) how helping you could benefit them/their project.
This effort on your part shows that you are serious. It qualifies you. Especially if you persist. (Now, you can’t persist to the point of annoying the person. There’s a line between persistence and bugging someone. I always preface any email I send to someone asking a favor with ‘hey, feel free to tell me to buzz off’, and I mean it.)
I hate to sound all zen master-ey but in my experience, it is doing the work that teaches you what you need to do next.
That doesn’t mean you can’t learn from reading (otherwise why have documentation or even this blog!) but that you need to actually try things outlined in docs. Even just typing the commands of a tutorial (instead of copying and pasting) will help you understand what you are doing.
The whole post is worth a read.
Dear new developer,
I enjoyed this post from Hanah Yendler on how to succeed as a new developer. Note that she is working at Eventbrite, a larger company (1100 employees according to wikipedia), so some of the advice may be a better fit for new developers at bigger companies.
A few of the pieces of advice really resonated with me:
Take responsibility for something that seems slightly out of your reach. One of my previous managers at Eventbrite told me that he wants me to be sitting just on the edge [of] fear because that’s where intense learning happens. I have a huge fear of failing, but taking responsibility means pushing yourself and growing as an engineer.
It can be tough to get a subject matter expert (aka an engineer more senior than you) to explain things on a level that you can understand –especially when they have very intimate and in-depth knowledge of a system or complex subject. This is where asking questions becomes essential. You can use questions to help guide them to the answer you are searching for.
Both of these pieces of advice are true when you are new to the industry and true when you have decades of experience. (Pushing yourself to the edge of your comfort zone is how you grow, and asking questions is one of the fundamental ways to learn.)
The whole post is worth reading.
This is a guest blog post from Don Abrams, lightly edited. Enjoy.
Dear new developer,
When starting out, the hard part is balancing two things:
- Asking questions
- Banging your head against the wall
Additionally, as a new developer you’ll likely be encountering something for the first time: a codebase that is really really large. Like large enough no one knows all of it. You’ll want to learn how to navigate the codebase ASAP. Every place is different. If you can checkout all the code and get the product running in less than a day, you’re at a world-class shop. If it’s more than a week, I’m sorry.
After you learn to navigate the code, my recommendation is then to learn and copy the patterns that other team members use. So your questions should mostly be “how did someone solve this before?” or “hey, have you seen anything like this before?” If you look at the code they referenced and still have questions, then bring it back up ASAP.
If someone offers to pair, DO IT! Tip on pairing as a junior: be the keyboard and basically have them tell you what to do. You’ll learn how they think about the codebase and learn to navigate it better. You’ll feel stupid when they tell you “just” to do something, but those are the things you need to know. (“just XXX” signals that XXX is complex thing that you’ll take for granted soon– documenting those will really help the next junior).
I also recommend reading a LOT of code.Then, as you get a better command of the codebase and team patterns (3-6 months), you can start asking questions like “why did someone solve this before this way?”
That’s when it gets fun.
Don Abrams has over 10 years of software development experience and recently moved to France.
Dear new developer,
Every company has its warts (aka issues, aka problems). I have never met anyone who worked for the perfect company.
So, go in with your eyes wide open and choose what warts your company has. You may be able to help fix some of them, but some will be permanent.
One wart to avoid: an indifferent team. One just punching the clock, trying to get through the day.
If a company is full of people who don’t care, then you’ll have trouble fixing any other issue. Customers will be an after thought. And work will drag. (Yes, places like this exist.)
That’s not to say that a place where people care will be unicorns and roses, but at least people will want to fix issues and serve customers well.
How can you tell from the outside if people don’t care? Ask questions like “how do you improve processes” or “what do customers love about what you do” or “what changes have you all struggled with over the past year” or “how do you keep up to speed on the newest technology”. If the answers to these indicate a lack of caring and empathy, then I’d shy away from that place of work. If you are already in it, make plans to leave.
PS You also want to avoid people who don’t care.
Dear new developer,
It’s paradoxical, but sometimes the best thing you can do is not write code. Remember, the value you provide is to solve the problem you are faced with (the outcome), not to write code. Custom code has value, but comes with costs. It needs to be deployed, maintained and upgraded. It has bugs. It requires a developer to change. It also has opportunity cost. Writing custom code to accomplish task A means that you won’t have time to accomplish task B, which may be either more urgent, more important or both.
There are a couple of ways in which you might solve a business problem with out writing a lick of code.
- Use a library or framework. For instance, I worked at a place where they had written their own database connection pool. Why? I never got a great answer, but it wasn’t clear to me that one of the open source solutions wouldn’t have worked. You need to have an awareness of such libraries to be able to propose this.
- Use a third party SaaS tool. I’ve seen people run their own in house git repositories. There may be good reasons to do this (including security or privacy concerns). But Github is going to give you a far better experience and unless you have a big team, probably better security and privacy. You need to know what the problem, the solution and the cost are to make an effective suggestion.
- De prioritize the work. I was at a meeting with a CEO and we were talking about continuing an effort to integrate a set of outside data sources. I asked why, and we discussed it a bit further. It became clear that the reason we were thinking about doing it was because of inertia. It became clear that there was no real business reason to do it, and we prioritized other work instead. A clear roadmap and the willingness to question requirements are helpful with this path.
- Do it manually. I was working on a startup and we had the need to occasionally refund customers. I could have integrated with the payment provider and had this case be handled automatically, but it was much much easier to document the process and handle it manually. Refunds happened rarely enough that there was no value in automating them. Here it is helpful to know how often the problem arises, how long it takes to fix manually, and how often it will arise in the foreseeable future.
Now, sometimes you may not understand the larger context of your work. You may propose a solution that isn’t the right fit, and there’s certainly nothing wrong with writing custom code to solve a problem.
In cases where I’m not sure I have full understanding, I always preface my questions with “I am not sure I have the full picture, but I think we could solve the business problem using solution A or project B, rather than writing custom code.” If you are working directly with the client, they likely won’t care, as long as the problem is solved. If you are on a team, the engineer or project manager running your project should have a good understanding of alternatives and why custom code might be the right solution. Most folks will be happy to share that reasoning with you.
In short, it’s better to keep your eyes on solving the business problem and be aware that custom code isn’t always the right answer.
PS No, this isn’t an April Fools Day post 🙂
Dear new developer,
Searching is 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.