Fewer Applications, More Interviews: How Professional Allies Can Help You Land Your First Jr Dev Role

This is a guest post from Dagny Wise. Enjoy.

Dear New Developer,

Even when your GitHub is a work of art, your portfolio is up and running, and your resume is looking good, it can be rough to get hired as a career-changer who’s never worked as a dev before.

Before you throw your money into an endless abyss of possible certs you could get to try to stand out, try leveraging what you already got – you!

A bit about me: I left my sales job to complete a coding bootcamp. It was part of my bid to get out of sales, and work towards a role where I can bounce between tech- and non-techy stakeholders. What follows is what I’ve learned from the process of job-searching as a career-changer during a pandemic, and landing my first job offer in the hidden job market. While I’m not a developer, the methods I’ve outlined below are useful to anyone trying to land their first job in a new role.

Think about it: unemployment is quite high right now, and everyone applies online. Many qualified, experienced people are among those unemployed. But take heart – you can differentiate by making professionally-minded allies.

What’s a professional ally in this context?

A professional ally is someone who is invested in your success. They might be a friend, family, former coworkers, folks you knew in school but didn’t really talk to, or strangers you’ve never met. You’d be surprised who ends up wanting to help you!

An ally does not have to be someone with hiring power, or domain knowledge, or someone who works somewhere you want to work, or even someone currently employed.

All of these things are awesome bonuses, but anyone who wants to help you may be able to connect you to more strategic people. And anyone who genuinely wants to help you succeed is already awesome, so it’s important to think of them that way.

How do you find your allies?

1). Make a list of all the broad categories of your life where you could connect with people. For example, your schools, former workplaces, that summer camp you did for years, all of it.

2). Mentally go through everyone you remember from each of those categories, and connect with the ones you remember on LinkedIn: everyone gets a message. Something short. It can be simple, but it should be at least a little personalized.

Something like “Hey person’s name, I was looking to connect with more people from name of highschool, and I was excited to find you on here! I hope you’re doing well.

3). If they ask you how you’re doing, respond organically, but focus on your career goals. 3-4 sentences tops. Conversational.

4). If they ask follow-up questions on your little intro, demonstrating interest in what you’re doing, congrats! You now have a new ally!

Why do all of that? Because professional allies open doors for you.

They can get you referrals at companies you want to work at, significantly increasing your odds of getting an interview. They can tell you about hidden market jobs, and they can help you make more strategic allies. And the best part: when you get your position as a result, YOU have the opportunity to become one. Awesome.

What it Looks Like To Make an Ally:

After doing all of the above, I connected with George, an acquaintance from high school. I didn’t immediately see what George could help me with because he’s a contract UX Designer and my dream was to work in Product. I told him what I was pursuing anyway, and he seemed genuinely interested in helping me. Great!

I went through George’s LinkedIn contacts and I found several people working in product, and a founder of a startup that George told me was looking to grow their team. I asked George if he knew any of these LinkedIn connections well enough to feel comfortable introducing me, and gave him some names. He said he was very happy to hit up 2 out of those names, and he did!

One of the product people got back to me, a VP of Product who I’ve talked to a few times via Zoom, and I’m still in touch with. It’s amazing to have someone so experienced in the field to bounce ideas off of, get advice from, and generally have me in mind when opportunities come up.

What It Looks Like to Get a Referral

Companies LOVE referrals – it saves them money when a good employee brings in another good employee, rather than picking from a giant pile of faceless internet applicants. It increases your odds to get a referral on your application – and you can get quite a few of them by nurturing professional relationships.

For example: I didn’t know anyone who worked at this awesome EdTech startup, but I saw them always topping lists of awesome places to work, so I knew I wanted a connection there. Not knowing anyone personally who worked there, I reached out to a couple people I’ve never met who worked in Product. One got back to me, and I coordinated a 20-30 min conversation via Zoom. She was super nice, answered my prepared questions, and said yes when I asked if she’d be comfortable referring me. I sent her my resume, and got an email from the recruiter later that day to schedule a phone interview for the role we talked about!

Fun fact: You can message strangers this for free on LinkedIn by “adding a note” to your connection request – no need to pay for Premium! Just make sure to introduce yourself, mention something specific about why you want to talk to them, and make a specific ask (ex: 20-30 mins of their time for a chat about their experience at company). Some won’t get back to you, but that’s ok.

What It Looks Like to Break Into “The Hidden Job Market”

Maybe you’ve heard of the Hidden Job Market? It refers to jobs that get filled but are never posted online, and professional allies are the best way to learn about these awesome opportunities.

For example: I reached out to a founder of a start-up George told me was looking to expand their team. We’ve had several interviews, and are currently in final talks about logistics. The role is as a Product Manager. I would likely never have had access to this opportunity without George, as it was never posted online.

Make Sure To Do Right By Your Allies

Professional allies are powerful! Maybe as a job-seeker right now you don’t feel like you have a ton to offer them. That’s ok! If someone responds with interest to you, you can proceed confidently knowing that they like to help people/you.

The best thing you can do, though, is do as much of the legwork as you can to save your allies’ time. Check out their profiles before you speak with them. Offer to send the Zoom invite. Keep the conversations within the agreed upon time frame.

And of course, say thank you.

If George introduces you to Jessica and Jessica gets you a referral for an awesome job, thank both of them. It can be a couple lines on LinkedIn, via email, whatever works. Consider keeping track of the folks who help you a lot, message the recurring ones every once in a while to say hey, or update them on your search.

As you develop into the professional badass you are destined to be, you will have ample opportunity to become someone else’s ally: you are working to pay it forward.

— Dagny

Dagny Wise is a a creative problem solver excited about leveraging her background in sales along with her passion for technology to bridge the gap between technical and non-technical stakeholders and solve complex problems.

Keep pushing through

Dear new developer,

One time I was working with an application framework that had poor documentation. I was trying to figure out how to use it to support a client’s project. But it wasn’t working.

I was less experienced and so had no idea why we’d chosen this application framework. I was simply tasked with making this particular feature work. Frankly, I don’t even remember what the feature was!

But I had to make it work. No one could help me (it was new to everyone). There was little documentation, I don’t recall if I filed a support ticket with the vendor, but I certainly should have. I searched the internet intensely. I ended up downloading a java decompiler to learn what I could about the framework and the class in question.

I finally solved the problem by decompiling a few classes. I found a bug in the application framework that I was able to work around. I did my job, even though I had to approach the problem from a non traditional angle.

Note what I didn’t do: I didn’t give up.

Sometimes you just have to keep pushing. Software development is hard.

By definition, the easy stuff is easy to do and therefore gets done relatively quickly. So you’ll send a lot of time on difficult things. Prepare for this and plan to work through it.

Tips for working through hard things:

Take breaks
Talk to others, whether in person or online
Keep thinking of different approaches
Remember the end goal

There are going to get hard. In technology there are ways to work smart and hard. Make sure you do both.

Sincerely,

Dan

How to get a job faster

This is a guest post from Taylor Desseyn. Enjoy.

Dear new developer,

Finding a job was hard for a new developer pre-pandemic…now during a pandemic it is just as hard but add in the fact that you can’t meet anyone! It can be daunting.

Here are my thoughts on how to find a job FASTER than most other job seekers.

Put out content

Put out content (especially on LinkedIn). You’re probably asking yourself. Taylor, I’m an introvert and not a marketer, what does putting out content have to do with finding a job? The answer? Everything. The fact we all are at home and cannot network has everyone on all major social platforms more than ever.

LinkedIn especially. LinkedIn is like tik tok. You can have zero followers and still gain a ton of traction. I know a handful of developers that have documented their journey finding their first job over LinkedIn and actually have landed their job because of putting out content.

Post at least once a day. This could be about an interview you bombed, or a question you missed on an interview and ask for help, or learning a new piece of tech and asking about one part of it. You should also be liking and commenting on other peoples posts as well!

Interview yourself

Video Interviews…Selfie style. This is a big one for me and only a few developers have done it. But guess what, the few that have, landed a job and one specifically because of this tactic.

Hear me out, every first-round interview is the same. Tell me about yourself, tell me your weakness (which we all turn into a positive), and tell me your greatest strength.

Why don’t you just video it up and answer these questions yourself and put it on LinkedIn and ‘pin’ it under the featured section on LinkedIn. So, every manager that visits your profile can see you! Here’s an example.

You need real world experience; get it

Capstone/code school projects aren’t enough. Long gone are the days of having a capstone project and it being enough to land a job. You need real world work experience so, if you can afford it, start asking around if you can help build small things for people. Every church needs help with their website, a lot of entrepeneurs need help with building stuff for free.

I get it, this area is such a divisive topic but for me, the only way to separate yourself is to get real world work experience and what better way to do that then volunteer your time?

Network, but don’t ask for anything

Now you probably are asking yourself, Taylor you said “put out content”, AND I have to now network?

Yes…yes you do. You need to make sure you are having one intentional video/phone call a day with someone in your network at a company that you want to work at or someone who does what you want to do.

You shouldn’t go into any networking call with a stranger asking for something. Be interested in what they do and how they got to where they are. Then ask for another connection but don’t ask for a job. Because when you don’t ask, you immediately endear yourself to that person so down the road if they get a job opportunity they will think of you first because you were different.

The big thing is at the end of every call, ask for a referral. Try to get another connection out of every call. My 55 year old dad did this in the restaurant industry and found a job in 6 months.

It works.

Leverage a recruiter

Most recruiters don’t place junior talent but the good recruiters can give you market intel, help your resume, help your LinkedIn, and can be just a general sounding board for you as you start searching for that first job.

— Taylor

Taylor Desseyn has been recruiting for over nine years and while he recruits on every skillset within technology, his main focus is on software engineers and developers. He has met over 4,000 engineers and helped place over 450+ people in their dream jobs.

Taylor has been very active in the community – he’s been elected VP of the .NET User Group (the second largest user group in Nashville) for 3 years. He has also presented at multiple other user groups within Nashville. Taylor has also been fortunate enough to get on the speaker circuit across the southeast, having presented at code conferences such as Code on the Beach (Jacksonville), Music City Code (Nashville), and Codestock (Knoxville).

Taylor has a knack for scaling teams as well. He has helped scale teams internally at Vaco up to 3x their initial size every stop he has been. He also was chosen to present at Vaco’s Global Conference on branding/marketing. Taylor is currently leading a team of 9 recruiters and has helped scale his currently technology team from $2 million in revenue to $6+ million in revenue.

Use the clipboard from the command line

Dear new developer,

I’ve already written about the power of copy/paste to save effort. And had a guest blogger write about how you should be focus on inspiration rather than imitation.

This letter is going to be extremely tactical and reveal to you two commands that I didn’t know until a year or so ago.

But they changed my life. Well, they at least made my work copy/paste routine better. And reduced my mouse usage.

I spend a lot of time in a terminal, on the command line, but often want to copy between a terminal and a browser.

I might want to do this to paste an error message into a search engine. Or copy and paste a config file into a stack overflow question. Or even just type up something in a text file and copy and paste it into slack so that I can write something thoughtful without dealing with slack’s horrendous editing interface.

To do so, you can use these commands:

On macos, pbcopy. On Windows, clip.

Before I discovered these commands, I used to select text with my mouse and copy it, then paste it. It worked, but was inefficient.

Now, if I’m writing that aforementioned thoughtful response to a slack message, I might do the following:

vi a
# write thoughtful response
cat a | pbcopy
# cmd tab
# paste to slack
rm a

I use the temporary filename a because as soon as I finish writing it, I’ll be copying it to slack, which is where the thought will live permanently. But I still get to use my text editor.

Again, you can use this for any kind of text that you want to copy from the command line into the system clipboard. Error logs, sample commands, text files, configuration, anything. Copy it all!

Hope this helps,

Dan

Take a tour with a different department

Dear new developer,

If you are totally thrilled with your job right now, stop reading. This letter isn’t for you.

Okay. So you may be unhappy with some aspect of your current job. I have some advice for you.

Take a tour with a different department at your current employer.

This won’t work for everyone. If you work in a company with only three devs in the department, there probably isn’t a lot of scope for switching things up. But if you work in a company with 20 or more developers, there probably are focused teams. And if you work for a company with 100s of developers, there are all kinds of specialized teams.

I worked at a consultancy with a couple of hundred people years ago. They had a dedicated database development group. I was not even unhappy with my software position, but I was really curious about the database folks. I talked to my boss and we arranged a tour of a couple of months where I worked exclusively with the database department.

I gained a deeper understanding of relational databases. The database group got a trusted helper who was happy to do whatever grunt tasks they handed me. My boss was able to let an employee explore something new and gain new skills, while being assured I would return in a reasonable period of time.

If this interests you at all, discuss the possibility with your manager at your one to one. Also, reach out to the team that seems interesting and learn more about their work. Just ask what they do day to day and you’d be surprised what they’ll tell you; people love to talk about themselves.

Now, some managers won’t want to let you go, even temporarily. I’ve been lucky enough to never have that happen, but if it does, well, that’s a good piece of data to know.

Doing a tour with a different department is a great way for you to spread your wings and try something new in a relatively safe environment. You’ll be a known, trusted quantity and there’ll be far less risk than if you were to take a leap to a different company and a different role.

Sincerely,

Dan

Ask for great hardware

This is a guest post from Perry Tiu. Enjoy.

Dear New Developer,

Ask for great hardware.

Ask for that latest MacBook. Ask for that extra built-in 2TB of flash storage. Ask for that 32-inch monitor. Ask for that additional vertical monitor. Ask for that standing desk. Ask for that Aeron chair. Ask for that expensive USB-C hub. Ask for that ergonomic keyboard.

Now you may be thinking that you don’t want to be perceived as a burden to the company, or that you’re coming off as greedy and needy. I get it. If you had to purchase all of this yourself, it would surely be an unpleasant hole in your pocket. We all get it.

Fortunately in the bigger picture, this amount is actually minimal for companies compared to all the other costs related to hiring a new developer (salary, staff hours spent on interviewing individuals, etc). Most well-run companies regularly take into account these costs as they grow and there are many reasons why they are willing to invest in their staff’s developer experience.

One of the more obvious reasons is improving efficiency and productivity: having a laptop with an additional monitor setup is generally better than without. Interestingly, there are also indirect, not exactly tech-related, benefits. For example, being able to satisfy a developer’s needs improves work satisfaction, which contributes to employee retention. As long as you justify using the amazing hardware at your disposal, the return of investment in the long run far outweighs the cost of the hardware.

So ask away, treat yourself and embrace what modern technology has to offer. Your company should be there to help you grow in your role so don’t be shy. But more importantly: share your experience. Let people know what works for you, what doesn’t. Countless times have I learned new quality-of-life improvements just from hearing or seeing someone else live it. Not only will your peers and friends appreciate the discussion, it is also a collective push to improve each other’s developer experience.

Oh and it is harder to ask for upgrades down the road than when you just joined.

Sincerely written on an outdated machine,

Perry

Perry is a Software Engineer and host of a podcast ruined by a software engineer.

Try to feel inspired, not envious

Dear new developer,

I struggle with envy. I find one kind particularly insidious. It’s the envy I have of someone I know online. I’ll see someone younger than me, or less experienced than I am, or less knowledgeable than me. But they somehow have 10x the Twitter followers, or have been asked to headline conferences, or have written more popular books.

In my darker moments, I see them and think “why them? what did they do to deserve such fame?” I’m not proud of these thoughts, but I definitely have them.

While all my emotions are valid, this envy isn’t productive. It isn’t even realistic. Why?

Do you ever curate your online persona? I certainly do (confessions of ugly envy notwithstanding). I’m certain that these internet famous people do as well. This means that I don’t know where they actually are in terms of happiness, success or fame. I know what they choose to tell me and what I can infer. But I don’t know what other aspects of their life are like.

Second, suppose I do find out they are living a tremendous life, with no issues. Maybe I get the chance to chat with them at a conference over beers. The other aspect that I need to keep in mind when I’m envious is that I don’t know how they got to where they are. I have no idea of the fires that burn in them, the sacrifices they’ve made, the late nights and hard choices they’ve endured.

So in short, my envy is unrealistic because I don’t know what their life is like nor do I know what their path has been to get to where they are now.

So, if the envy is unrealistic, should I ignore it? I don’t think so. What I try to do, not always successfully, is turn it into inspiration. After all, the reason I feel envy is because I want what they have. So why not see what they’ve achieved as a goal and go get it.

They may have learned and worked toward what they’ve achieved in public, in which case I have a blueprint to follow. Or, they may not have done so. In that case, the mere fact they’ve achieved something indicates to me that it exists and can be done. Bannister ran a sub four minute mile in 1954. It became possible, and others followed:

By the end of 1978, over 200 runners had broken the once impossible barrier of the four-minute mile.
https://www.mayooshin.com/four-minute-mile/

So rather than feeling unrealistic, unhelpful envy, I look to the people on the internet who have shared their accomplishments and feel inspired. Wow, someone came out of school and self published a book! Someone else went from three hundred followers to thirty thousand. And someone else built a side hustle into a business. All these things can be done with effort.

I can be inspired all day long, and it is far more beneficial to my mental well being than envy. However, both emotions don’t matter much in terms of getting things done.

This leads to the last point. When I see someone with large achievements, I can choose to follow in their footsteps. Take their accomplishments as my goals. Or I can choose to think about what it might have taken them to get to where they are, what sacrifices they’ve made. That leads to the most important question when I start to feel envy.

Am I willing to put in the time and the effort to try to get what they’ve got?

Sincerely,

Dan

Make it open source

This is a guest post from Eddie Jaoude. Enjoy.

Dear New Developer,

I will be the first one to tell you that it is not essential to have a degree in computer science to become a developer. My own journey started with a degree in engineering and falling into code as a mix of a hobby and also by necessity in my first graduate job. I have seen so many others in the tech community follow different paths to becoming developers; such as primary school teachers and historians.

Whether you have always wanted to become a developer or whether this is a new start for you, the likelihood is that you will be looking for learning resources from blog posts, YouTube videos and online courses. There are so many resources available, many of which are free, which means that you can improve your abilities without having to leave your house – which in a Covid era is quite handy.

However I would say to you – do not fall into the trap of getting stuck in “tutorial hell”. Thirst for knowledge is a great thing – and a good developer will realise that at no point in their career will they know everything and you do need to keep learning.

This is a little like going to the gym: you’ve decided you want a six pack – your trainer has shown you where the three different ab machines are and how to use them, you have watched endless videos on the best time to train, how long for and what food you should be eating. But it won’t be until you do that first ab crunch – which lets face it, won’t be perfect, that you will embark on your journey to achieving that six pack.

So my advice to you is – pause the video tutorial and build something. Apply what you have been learning and let go of the idea that it will be perfect. What is perfect today can be improved by your experiences tomorrow, the day after, in a year’s time and so on.

My second piece of advice – which is perhaps the one I am most passionate about as it forms the whole ethos of how I work: make it open source. I don’t want to assume that you know what open source is. It took me a few years into my career to find out about it. I was using open source tools in my day job and thinking how great it was that there were so many valuable free available tools out there that anyone could use. I was also beginning to network more and everyone kept talking about open source, which got me interested in finding out more about this community which works publicly and transparently to resolve software problems. I didn’t want to just take, I wanted to give back.

As a new developer you might be worried that you are not yet at a stage where you can give back and contribute. There is a misconception that you only have something to teach when you have reached a level of seniority in your career. But everyone has a voice. Don’t think that just because you are at the start of your career that all you should be doing is asking questions and seeking help. You do not want to be a drain on the community; at first you will get the help you need, but soon community members will see you are just there to get a quick fix to your problem and then drop off the face of the earth until you hit another stumbling block.

Beginning to get involved is not always easy – it might feel like you are entering an old fashioned boardroom meeting full of senior colleagues and you are under immense pressure to say something…anything at all… which really just contributes to you feeling anxious and insecure about your abilities and in a worse case, can stop you from taking that step.

So start small. Github in my view is a fantastic (and essential) way to start your journey into open source. Firstly, find a good repository:

Go to the Issues section which lists your issues, clear the search box;
Add the search parameter for the label “good first issue” and consider including a language;
This will list all issues which will match this criteria and from there have a look at the repositories and see which ones seem interesting to you.
Check the closed Pull Requests that have not been merged: it is completely acceptable for a project maintainer not to accept pull requests – but were these rejected in a friendly and constructive manner?
When making a contribution, focus on adding value (don’t just suggest a change for the sake of it) and being respectful towards the project maintainer’s time;
Bonus tip: check the insights tab on the repository to see if the project is inclusive for things like code of conduct.

You might ask – “But why should I make my projects open source?” Why would you not?

Is it because you hope your project will become your revenue stream and you do not want to share this with others? Making their project open source certainly did not hinder Red Hat when it was sold for £34 billion.

Is it because you lack the confidence and do not want to feel exposed? How else will you learn if you do not put yourself out there?

By making your project open source you widen the number of people you can learn from massively, as well as making connections which might even help further your career. When recruiting for my team I no longer spend hours quizzing a candidate about the bullet points in their CV. I go to their Github account where I can see exactly what they can do and how they interact with others.

Making your project open source is probably one of the best calling cards you can have as it showcases what you are about, not only from a technical perspective but also how you will engage with others. Whether you are looking for your first role as a developer, have secured one with a small start up or have embarked on a graduate training programme with one of the large tech companies, you need to know that no project is limited to one person only. You will need to collaborate with UI/UX, testers, product owners …the list goes on.

You may come across really well in a face to face (or virtual!) interview – exuding confidence and a team spirit. You also might not. By having an open source project your prospective employer and colleagues will be able to see how well you do with receiving and giving feedback and how you act upon this. This is a skill which needs to be learnt and open source projects are the forum to do it.

You might have a job where you work your own, or perhaps you work in a team with quite similar views and levels of seniority – these things might not be conducive to receiving and giving feedback.

By making your project open source you are interacting with people from all over the World, with different levels of seniority and most importantly different perspectives. That, New Developer, can only be a positive for your technical and personal development.

— Eddie

Eddie Jaoude is an open source advocate and believes open source is for everyone. Check out his GitHub and YouTube.

Google can’t help if you don’t know the words

Dear new developer,

If you don’t know what you don’t know, it’s hard to learn it. There are so many resources for learning, but if you can’t find them, you’re going to have a hard time taking advantage of them. Sometimes you need to spend time learning what you need to spend time learning. That is to say, you need to learn the broad outlines of a segment of knowledge before diving in.

This time spent prepping your understanding of swathes of a domain will be useful because it will accelerate your learning in the future, letting you grasp concepts and find resources more quickly.

Let’s say I got hired by a company to write a compiler, which would be a new area of software for me. Here are some things I would do if I were trying to learn this new domain.

Glossaries

I’d look for some glossaries about compiler design. Here’s the first result from Google when I search for “compiler design glossary”. Reading this would help me understand the meaning of words I might know from other contexts, such as “array” and “value”, but would encounter when reading more about compilers. Knowing the jargon of a domain is extremely helpful when you are searching to see whose shoulders you can stand on, as well as communicating with your team members.

Pattern match

Matching patterns is something I’ve done many times. I take something I understand fairly well and see whether it matches up to a new concept, domain, or technology. In this case, I might read about a compiler for parsing regular expressions. I understand how regular expressions work as an end user, so it won’t be as much of a leap as if I were to try to study a compiler for C. Here’s a search result that I might work through.

Books and videos

If I have time, books and videos can be very helpful at getting a wider view of a domain. Sometimes it’s hard to know which book or video to invest your time in. By looking at reviews on sites like Amazon and Youtube, you can leverage the wisdom of many people. I’d probably start with one of the top books here, were I to need to jump into compiler design. When I do this, I don’t feel the need to read the entire book or watch every minute of the video.

Twitter

You can use Twitter to “get smart quick” too. Basically, you can follow folks who are highly regarded by other folks in the same domain. Wesley did a great job of explaining it, so I’ll just point you to this video. You want to watch between 15:53 and 20:00, where he talks about getting smart around “quantum computing”. Once you know who to follow on Twitter because they are respected by the community, you can start figuring out the words and concepts they use.

Follow some rabbits down holes

I’m a big fan of timeboxing investigations, and I always tell team members I am mentoring that they shouldn’t spin their wheels too long; far better to ask a team member. But sometimes, when you are exploring a new domain, you should spin your wheels a bit. Follow some paths and see if they end up where you thought, or if they were dead ends. In this stage of knowledge gathering, there are no wasted efforts. Any time you “waste” investigating or following some threads of discussion will compound and save you time in the future. Do take some notes, either mental or written (I like a blog post, as I did here). Don’t feel like you need to come up with any firm answers. And feel free to timebox it, just make the time limit higher than it would be if you were actually trying to solve a problem.

Take a class

One time I was working on a project at a real estate brokerage where we wanted to do statistical analysis on property data. I didn’t have much background on it, so I ended up taking a free class from Coursera. This is a substantial time investment, but for foundational knowledge that you can leverage across other parts of your life (I’m a lot more suspicious of stats I see now), the additional time can be worth it.

Pick the technique that resonates with you next time you have to get smart quickly about a topic or technology. Spend some time investing in your upfront knowledge and I promise it will pay dividends as you dig deeper.

Sincerely,

Dan

Use your shell’s history

Dear new developer,

The command line is a powerful tool, and writing shell scripts lets you write a series of commands once and replay them any time you like.

But sometimes you will write a series of commands without putting them into a script. This may be because you are exploring a problem or because you haven’t bothered to put together a script. No sense in making something repeatable if you aren’t sure exactly how you are going to repeat it.

But you may want to look back over past commands you have run, whether to run them again, modify them or even just remind yourself what you’ve done. For this, the shell history is very handy. Another time I often look at the shell history is when I am signing into a machine that I don’t visit very often. Perhaps there’s a command to look at some log files that I know, distantly, in the back of my mind, that I ran four weeks ago. I could have documented it, but maybe I didn’t. If I look in my command line history, I can see it.

All of the examples below are for the bash shell. Why? This is a very common shell, more modern shells like zsh are roughly compatible, and most importantly, this is the shell I know.

To use the shell history, first you have to know it exists and then you have to see it. You can also view the history by typing history in your terminal or at the shell prompt. Here’s an example from one of my shells:

  520  vi text.adoc
  521  git status
  522  git add text.adoc
  523  git commit -m "Initial pass at examples and documentation."
  524  vi text.adoc
  525  git add text.adoc
  526  git commit -m "Added one more example." text.adoc
  527  git push origin add-example-docs
  528  history

Each line is one command and is numbered. From here, I can repeat a command by number. So if I type !524 the command vi text.adoc will be run. I can also search for a certain string by using grep:

history | grep 'ssh' # will show all my ssh commands

The above commands are all pretty simple, but you can also link commands together. I often will do something like this:

cd directory && mvn jar && cp file.jar ~/place/jar/goes && cd otherdirectory

Once I get this command right, I can run it over and over again by referencing its line number. The && means that each command has to succeed before subsequent commands are run. So if the mvn command fails, the cp will not run.

This is fine for running tasks that are not going to change, but what about if I want to edit my previous commands. You can navigate the history by using the arrow keys (there are other ways as well, but arrow keys are the default and most accessible). Each up arrow takes you one step further back in your history, and each down arrow takes you one step forward. At any point you can edit the command you are currently on and hit the enter key and run it.

The bang shortcuts

If you know you want to edit whatever command you ran previously, you can use some bang operator shortcuts (so called because “bang” refers to a !). Let’s say I want to get the latest main branch from my git repo.

Suppose I run the command:

gti fetch origin main

I see an error message because I misspelled git. Whoops. I can type:

git !*

!* expands to everything except the first argument in the previous line, so this is the command that is run:

git fetch origin main

Now I want to check out the main branch

git checkout !$

!$ refers to the last argument of the command, so main in this case. The command which is run is then:

git checkout main

Knowing these shortcuts will help you avoid tediously hitting the arrow keys, editing the previous command and re-running it. There’s one more bang shortcut which is very useful. Suppose I want to install something on a linux box:

apt-get install pkgname

Whoops again! I’ll get an error message because I’m not root. Easily fixed by typing:

sudo !!

!! expands to the entire previous command, so what is actually run is:

sudo apt-get install pkgname

I use this very often when working with linux on the command line.

Controlling what is saved

You can control how much history is kept. Sometimes on my development machine I keep an infinite amount of it. I’ve also been on production instances where there was no history kept, I believe as a security measure. Remember, any command you run, including opening up a database connection using a command line client, will be kept in the history buffer. If you put a password on the command line, it will be recorded in this history.

To avoid that, don’t put the password on the command line. Another trick is to set the HISTCONTROL variable. When this is set to ignoreboth any command you type with a space in front won’t be stored in the history.

export HISTCONTROL=ignoreboth # previously set
echo "hello" # included in history
 echo "goodbye" # not included

You can also control explicitly how many commands to store in your history with the HISTSIZE setting:

export HISTSIZE=2000 # will save 2000 commands

Finally, be aware that all the bash shells opened share the same history file. Unless you take special care (as outlined here) the last one closed will win.

Being able to quickly re-run commands you’ve built previously, whether unchanged or not, can be helpful when you are navigating around the command line in pursuit of your software goals. Knowing a few history commands lets you do so.

Sincerely,

Dan