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

How to criticize code

Dear new developer,

Criticizing code (and software solutions in general) is an important skill. It helps transmit norms, increase team knowledge, and improve solutions. But it isn’t something that comes naturally; at least, I had to learn how to do it. Similar to learning how to edit other’s essays, you must learn how to critique team member’s programming.

First, understand the context. There are two types that matter. The first is the business context. What problem is this system trying to solve? What limits does the business have (time, money, labor, understanding)?

In a startup, some of the code being written will be quick and dirty, because the startup is trying to find something that people will pay money for. Rapid exploration is more valuable than perfect architecture and maintainability.

You also need to understand the technical context. What is the scale/timeframe/level of the team’s knowledge? All of these things should inform your critique. I expect different things from an adhoc script in a data pipeline than I do from an embedded agent shipped to customers with little chance of future updates.

If you are part of a team, you may know these contexts, but they shift over time. So it’s always worth double checking before you begin a review to make sure you aren’t holding outdated assumptions. This can be as simple as a quick conversation with the author or team lead. It’s also helpful to regularly have these so that the entire team can be in the same mental space in terms of the engineering trade-offs they make daily.

Next, determine “which hill you want to die on”; that is, what is important enough for you to comment on. Which aspects of the code are important to you, based on personal experience, team goals, or ethical considerations? If you don’t know what the team values, ask! And then write it down so that others can benefit.

What you want to do with a review or critique is walk a line. You want to question and provide actionable feedback so that you and the author can improve the code and understanding of the system. But if you provide too much, the author may be overwhelmed or, worse, brush off your comments. You can ask what kind of feedback the author prefers; some folks have thicker skin than others.

Don’t focus on the small stuff. It feels like an easy win, but it really isn’t helpful. If you must give such feedback, preface it with “nit”. In fact, if you can automate away questions like spaces vs tabs or where curly braces go by using a linter that runs before a PR can be opened, all the better. Intent and high level feedback is where most of the value of code critiques lives.

Finally, a note on tone. You can be harsh with feedback, but don’t mix up someone’s implementation with who they are. They likely do that enough themselves; I know I sometimes get wrapped up in my code and take it personally when it is found wanting. The tone I find works best is one of assuming positive intent, but asking tough questions along the way. Trust that your team member has done the best they could, and try to focus on improving it and educating the both of you.

The end goal is to bring the code up to the current standards, or slightly beyond, of the codebase and team. Attacking anyone personally, even if they made a really ignorant implementation decision, actively undermines that goal in the future. I find that harsh feedback delivered in a kind tone is more effective than the reverse.

Sincerely,

Dan

Think first about what problem this is solving and for whom

This is a guest post from Kate Catlin. Enjoy.

Dear new developer, 

Welcome to tech! Wow, I remember those days– Confusing, exciting, challenging. Nothing is certain except that you are in for a wild ride. Hold tight! 

The advice I’m writing to share with you today is this:

Before you write any code, think first about what problem this is solving and for whom.

As a little background, I’ve spent my whole career in tech. I’ve had two stints writing code (once in Android and once in Ruby) and neither lasted long. The rest of my career was a journey through Community Management, Sales, Startup Foundership, and now Product Management. While I love code, I love understanding people’s problems and figuring out how to solve those as well. That side always sucked me back in. 

Even in my roles where I wasn’t a developer, I’ve always interacted with developers. Many of them were new to the industry, just like you. The ones who have since excelled in their careers were the one who embodied the advice I just shared.

And so, every time you pick up a new Jira ticket or sit down to complete a new requirement, I suggest that you ask yourself the following questions: 

  • Who does this solve a problem for? 
  • What is the problem they’re trying to solve? 
  • How does this ticket solve it? 

There are three reasons this is going to help you out. 

First, it will keep you motivated. 

I think software development is one of the closest real-life professions to having superpowers. 

Why? Because your job is to use skills that most don’t have or understand in order to solve someone’s problem. 

Some of the problems you’ll solve may be big– Maybe you’ll work on an app that facilitates financing for renewable energy and measurably reduces climate change emissions. Some problems may be small– Imagine someone quarantining alone who misses their grandkids and has tried not to cry all day. Perhaps they have a slightly-less-frustrating time ordering a gift to send someone because you fixed a bug in a website’s UI. 

The world is a tough place to exist sometimes, especially in a pandemic. As a software developer, you get to use your powers to help make life a little easier for people. Remember that! Focusing on the problem rather than other things (like the shiny tech) will help you do so. 

Second, because you can start to push back if you see an easier way to solve that problem. 

A few months ago, I prioritized a new feature for CircleCI that would allow software developers, our users, to import Environment Variables from one project to another. I wrote up a long list of acceptance criteria involving multiple screens and checkboxes. 

The junior developer who picked up the Jira ticket for that feature was someone who regularly practiced user empathy. He paused, thought about it, and then suggested a simplified approach.

The simpler version worked! We were able to ship the feature in half the time, and it still resulted in a measurable lift to organizations adding new projects. This was good for the user, good for the developer, and good for the company. 

This is just one example of many I can name where by embracing user empathy, our team has solved more people’s problems faster. And so can you! 

Third, because it’s how you advance in an organization. 

Product thinking is so important at CircleCI, it’s a skill we specifically review our developers for during our annual review cycle. A minimum-threshold rating is necessary for a promotion. 

This is obviously not true of every organization, but in no case will the mindset not serve you well. Leaders simply need to understand why we’re building what we’re building for our users. How else could they help us achieve the future we’re working together to bring about? 

I would love to hear how a user-empathy mindset works for you. 

Everyone’s path is different, and every organization values different skills. You can find me on twitter at @Kate_Catlin, and I’d love to hear from you! 

Sincerely, 

Kate Catlin

Kate Catlin is Senior Product Manager of Growth at CircleCI.

Why and how to improve your writing skills as a software developer

This is a guest post from Allie Cooper. Enjoy.

It’s one thing to be able to write good code, but professional written communication is something else entirely. The ability to efficiently and authentically communicate using written language is an often ironically underrated skill in software development.

This is something that new developers need to get over very quickly. “Obsessions with patterns and algorithms don’t serve anyone’s mission by themselves,” explains engineer and career coach Minh Pham. “While coding might be your latest skill set, it is by no means an engineer’s only skillset. Remember that at the end of the day, it doesn’t matter if your code is ugly, fancy, verbose or concise – the value you create matters. Strive to be an excellent communicator, a quality teammate, and an outstanding human.” In today’s increasingly digitized workplace, achieving these qualities means honing your professional written communication skills.

Writing is Essential to Software Development

Any veteran developer can tell you that non coding-related writing is part and parcel of the daily grind, which includes writing tons of bug reports, notes for yourself, documentation for co-workers, and other technical discussions over chat or e-mail. You might also be tasked with explaining technicalities in ways that can be easily understood by clients. And as Inc points out, all of this generates a permanent record of any and all significant ideas, incidents, and other facts pertinent to how you’ve handled the job. In software development, the way you write and communicate over work platforms defines a great majority of your work history.

While writing code defines your raw ability as a software developer, your written professional correspondence tells the story of your ability to work with others in an inherently collaborative and complex field. Today, the sudden digital migration brought on by the global health crisis has only made professional writing a more integral skill for thriving in the new and increasingly web-based workplace. This is as true for experienced developers as it is for those who are looking to pick up the skills necessary for the job, which brings us to our next point.

The Future of Coding Education is Written and Online

From basic coding courses to advanced degree programs, more and more future developers are learning essential skills through online means. And the pandemic has only increased their numbers. For instance, Code Platoon Coding Bootcamp online basic coding courses have allowed the U.S. Department of Veteran Affairs to continue offering software development skills training for veterans as well as their spouses. And for safety reasons, all classes have been moved online.

Meanwhile top universities have also made this switch to training software specialists online. Maryville University’s online masters in software development is an advanced degree program that’s 100% web-based as well, with the perspective of producing future software consultants, UX designers, web developers, and DevOps engineers. And while these programs do include video conferencing classes, the majority of the work is through written communication. As natives to online work, the developers trained in these online programs are already developing the writing skills necessary to thriving amid the current digital migration.

In short, the field of software development is only getting more competitive and web-based. And while there’s no shortage of genius code writers for companies to cherry-pick from online universities and coding courses, the combination of a great coder and a great online communicator remains rare.

Practice Makes Perfect

Whether you’re already coding for a living or still learning the skill, you already have plenty of opportunities to hone your professional writing skills. Strive to be succinct and straightforward with every chat message or e-mail before hitting send. Put yourself in other people’s shoes – think about how the message you wrote will affect you if you were the one to receive it. Remember that every unnecessary word only muddles already complex conversations about technical specifications. Grammar is important, but so is writing with the perspective of being as empathic and as concise as possible – which can also allow you to develop a writing style that won’t require grammatical gymnastics. Never play to your emotions and always write with a collaborative mindset. The better you can communicate with the written word, the more value you can bring to any software development effort.

Allie Cooper is a freelance tech writer who specializes in I.T. and software development. Her mission is to help software developers further their careers. In her free time she plays online chess and sails.

Understand the use case

This is a guest post from Christie Brandao. Enjoy.

Dear new developer,

It’s easy to get wrapped up in only focusing on the deeply technical aspects of your job, especially if many parts of the stack have technologies you haven’t worked with yet. As your career progresses over time, you will be improving the quality and readability of the code you write as well as your problem-solving skills. This takes deliberate practice, but you’re already used to this! At the beginning, it’s natural for all your energy to go towards getting up to speed with the codebase and learning how everything works together. My advice is to take some time to also understand the use case.

At the core of it, your job is to be building something that will provide a positive business impact through your development skills. Ignore the urge to dive right in and start coding and instead, take some time to learn the bigger picture. Focus your energy on gathering as much information as you can to start building your foundational knowledge of this area of the product. You can start small! When asked to build upon a feature, for example, don’t just take the ticket at face value. Ask questions (to yourself or others) about how the current feature is currently working. What are the difficulties people are having using this feature? How is this going to be an improvement to the current process? Once you have a good grasp on the ticket level, it’s time to learn about the bigger forces that impact larger business decisions. You never know, maybe your fresh perspective will offer valuable insight that no one else has brought to the table.

— Christie

Christie Brandao is based in Columbus, Ohio. She is a Full Stack Serverless Web Developer for Branch, a tech-forward insurance startup focused on giving instant prices for home and auto with just a couple questions.

Make the ask

Dear new developer,

I’ve been surprised by how often I get a response from people I consider “famous”. A few examples.

  • Brad Feld, a well known venture capitalist, was willing to do a sixty minute AMA for the Boulder Ruby group. (If you want to watch the video, it was recorded.)
  • I asked a question of Patrick McKenzie years ago about whether I should write a book about testing ETL jobs with Pentaho Kettle. (Short answer: no.)
  • The guest posts on this blog.

How can you get help from someone prominent? I’m going to assume that you have someone in mind who you want to ask a question or otherwise get help from. Let’s say you are working on a post about React and you want someone to give it a review to make sure you are on the right path.

Find out more about the person. This involves some research, because you want to ask them for help on a topic they are interested in. Many people have profiles online, so review them to tune your “ask”. Google plus social media is your friend here. You don’t have to do exhaustive investigation, but if you can tune your question to their interests, you are more likely to get a response. It can also really help if you reference anything they’ve shared that is relevant to the question. If they recently posted about Redux and how it is awful, mention that you’ve read it and make an intelligent comment about their argument.

Next, get their contact info, or find it. So you need to do some more research. Lots of people make their email addresses known; that’s a good signal that they want to respond to email. I’ve had some luck with Twitter direct messages, Slack DMs, and LinkedIn messages. I’ve not had luck with public outreach (@ing someone on Twitter, for example). Find out how this person responds to others. I haven’t run into this, but I suspect there are certain people for whom Youtube comments, Tiktok messages, or Twitch DMs are the best form of contact.

Interact with this person before you make the ask. Follow them on Twitter. Share one of their posts to an online community. Comment on their blog. If they write a newsletter, subscribe to it. Even better, respond to one of their newsletters; even if someone has 10,000 subscribers, the number of email replies they receive is for each email is nowhere near that number. If you respond with a cogent comment, you’ll begin to build a relationship with them. Put in some work and you’ll also have a better idea if they are even the right person to ask.

Make sure your request is reasonable. Asking for feedback on your post is fair. Asking for 30 minutes of face to face video chat to discuss ideas is less so. Requesting someone promote your post to their followers is lame.

When you make the request, make it easy for them to both understand what you are requesting, the timeline, and the means of fulfilling the request. Here’s a good request:

Hiya <name>,

Would you be interested in reviewing my blog post about React deployment strategies? I have a blog focused on React front end development.

I was thinking that something on this topic might be up your alley. I saw your rant on Redux on Twitter and thought it had some great points. But one thing I wasn’t clear about: Redux sucks, but what is the alternative?

I’m looking to get this blog post published in the next week. If you are interested, I’ll send you a google doc (unless you would rather some other format; let me know). If not, no worries, and thanks for sharing your thoughts on React! I have learned a lot.

Thanks,

Dan

In this note, I have a single, reasonable request. I outline the timeframe; this makes it easy for the recipient to determine if they can possibly fulfill it. I let them know that I know who they are and their opinion on this technology, as well as that I’ve actually read and understood some of their opinions. It’s also important to make it easy for people. Google docs work for a lot of people for reviewing documents, but not everyone.

What a note like this does is encapsulate everything that this person might need to know about the request. There’s no back and forth about when the review would need to be finished. This makes the decision easier, which is what you, as the asker, should aim for.

Pick people at the right level of prominence. Don’t ask the creator of React to review a basic blog post. But if you saw someone speak at a local meetup about React, they’d be a good choice for this request. If, on the other hand, you’ve written an in-depth piece about the performance of React deployments in various scenarios and haven’t seen anything else like it, that might of more interest to someone more prominent, possibly even the creator. As long as you are thoughtful in your request, asking prominent, even famous, people is fine. I’ve been surprised at who has replied to my requests.

Next, follow up once or twice, but don’t bug them. The more prominent the person, the more they are pinged. (This is another reason to ask someone less prominent; they’re more likely to respond.) I always follow up a week later. Give them plenty of chances to say no. I always like to say “feel free to tell me to buzz off if this won’t work for you now.” But don’t give up after sending just one message; we all deal with overflowing inboxes. Patrick replied in 24 hours; Brad responded quickly but it took months to have schedules line up. If they say no, you can thank them, ask for a referral to someone else who might be able to help, or ask if you can follow up in a few months.

Finally, if they say yes, make sure you follow through on the request. For the React blog post example, make sure you send them the google doc, incorporate their feedback, and publish it. Send it to them with a note of thanks after you’re done. This completes the loop and lets them know you didn’t waste their time.

Asking someone prominent to help you out is not as hard as it sounds. Make sure you do your research, make a thoughtful request, and follow up. Not everyone can help, but some definitely will.

Sincerely,

Dan

Interviewing at a FAANG in the Midst of COVID

This is a guest post from an anonymous FAANG engineer. Enjoy.

Dear New Developer,

In 2020, one question lurks in all of our minds: What the hell is going on? And yet, for many of us, life not only goes on, it presents exciting new opportunities. Towards the end of 2019, after six years of working as a software developer, I felt it was time to leave my second job. The familiar faces were rapidly disappearing, and I just wasn’t finding the work fulfilling anymore. I entertained a couple calls from FAANG recruiters, but I wasn’t particularly excited about any of them. I assumed I was going to find The Perfect Startup™ at which to spend the next phase of my career. I was complacent. I had endless excuses for why this wasn’t a good time and why my job wasn’t so bad. I could spend another year there.

Little did I know that the “another year” in question was going to be the craziest year the world had ever seen.

For personal reasons, I did not interview at all for the first month and a half of 2020. I even scheduled a phone screen with a FAANG, but due to a family emergency I rescheduled it and then forgot about it until the night before. Oof. I pride myself on my algorithm skills, but three years without interviewing is enough to make anyone rusty. I didn’t fail the phone screen, but I didn’t pass it either – instead, I was asked to try again. That was a wake-up call, and it made me really want to succeed at the interviews that I had previously not cared about.

My first tip, for anyone interviewing in 2020 or any other year: Grind LeetCode. I cannot understate how important it is to build muscle memory for the coding portion of your interviews. You don’t want to spend fifteen minutes thinking about whether you should use a Queue or a List (as I did), you want to spend that time solving the actual problem. Anyway, after that experience, I practiced every night (and some days) and easily passed all of my phone screens.

Less than a week later, COVID struck and my office asked me to work from home until further notice. All good, this should just make it easier for me to spend time on interviews, right? I assumed it would just be a temporary exercise for the next two weeks. Little did I know, all the companies, FAANG and other, which I was interviewing at would soon close their doors as well. I started panicking – what was to come of my on-site interviews? Well, some of the smaller companies didn’t feel comfortably hiring remotely, so those processes were dead in the water. All the FAANG companies assured me that I would get the full on-site interview experience through the magic of videoconferencing. I was not happy about this at all. I’ve always prided myself on my ability to connect with other people, so I feared that this would be lost over video. I shouldn’t have worried. All my interviewers made an extra effort to connect with me due to the circumstances, and I actually felt more comfortable than I ever had for an in-person interview. Thus, my second tip: Relax. Yes, times are extremely weird right now, but they’re weird for everyone. Have fun and enjoy the process.

I went into the interview process with a pretty good idea of which FAANG I wanted to work at. Based on what I knew of the internal culture, the company’s impact on the world, and my expected daily happiness, I had already decided where I wanted to be. However, if I didn’t receive an offer from that one, I was more than happy to work for any of the others I was interviewing at. Thus, I treated them both as practice interviews and as high-stakes challenges. Ultimately, I aced all of the interviews, received offers from all the companies, and immediately accepted the one I had been thinking about. I could not have been more thrilled. I attribute my success to two things, preparation and routine. Preparation was already mentioned in my first tip – grind those practice problems. I did over 100 problems on LeetCode in the month leading up to my interviews, and I even wrote up solutions on that website as a way to practice my ability to explain to others.

As for routine, my final tip is this: Build a stable routine. This is something we software developers struggle with even in years that are not 2020. When the lockdown first started, I felt lost. I worked until midnight because there was no reason to stop. My diet and exercise slipped. However, once I turned that around, I felt the ability to compartmentalize and plan. I set a regular bedtime and waketime. I started cooking myself meals at regular times to replace the ones from the office. I ordered a pull-up bar for my doorframe so that I could exercise any time I passed through it during the day. Once my life and health were in order, it was easy for my brain to focus on the fun part: passing those interviews.

— Anonymous