Tag: excerpt

The Surprising Number Of Programmers Who Can’t Program

Dear new developer,

This came up in a Hacker News comment thread recently:

I’ve been working since the 90s and I never attempted to do FizzBuzz. Is it really relevant? Maybe to screen junior developers out of college?

And the response

So, as someone who spends maybe 20% of their time hiring, it’s still a very effective screen. You wouldn’t believe how many people can’t do it. People at big companies, respected places. It’s surprising.

I find it truly surprising. Here’s a post from 2007 about the same issue, so it’s been around a while. From that post:

…I’m starting to get a little worried. I’m more than willing to cut freshly minted software developers slack at the beginning of their career. Everybody has to start somewhere. But I am disturbed and appalled that any so-called programmer would apply for a job without being able to write the simplest of programs.

As a new developer, realize that

  1. You are going to stand out among other applicants if you can program.
  2. If you can’t program, you need to fix that asap.
  3. There are some folks that are just not effective programmers who somehow are in the profession (or seeking employment). You may end up working with and for some of these people.

So, make sure you practice programming. My letters have been about some of the other aspects of software development, but if you can’t do the basic work, you’re going to have a tough time. That’s like a baseball player who can’t run. Doesn’t matter how good someone is at catching a ball or hitting, if you can’t run, you’re going to be fundamentally disadvantaged at baseball.

Sincerely,

Dan

Tips for using email well

Dear new developer,

Writing great emails is a key skill. For all the hullabaloo about slack, emails still rule the roost when it comes to cross organization communication. This is because everyone has email, it is auditable and uneditable once sent, and requires no special permission beyond knowledge of an email address.

Email is great at conveying information, but horrible at conveying context. It also can be unclear and ambiguous. Because email is asynchronous, ambiguity causes slowdowns and confusion more than ambiguity in conversation (where you can say something like “when you said tomorrow, do you mean Saturday or Monday, the next business day?”).

This post has some great tips on how to write great emails. From the post:

Avoid using only temporal adverbs/nouns like yesterday, today, tomorrow, two hours ago etc but include also the specific dates/times otherwise they might be misunderstood or require from recipients to check the email’s sent date/time to calculate the actual time.

and

Use bookmarkable links when you refer to something that would eventually require from the recipient to search for in another platform.

There are a number of other great tips for writing clear emails in this post. The author also provides before and after examples, which really illustrate the points.

Worth a read.

Sincerely,

Dan

Write a brag document

Dear new developer,

You will encounter good managers and bad managers in your career. I’ve found that one common thread for all managers is that they are busy. Busy with meetings, busy with coordination with other teams or parts of the business, busy putting out fires, busy with helping team members. Busy busy busy.

They also will likely be responsible for your career. Promotions, compensation increases, title changes. A good manager will want you to be challenged and grow and learn.

However.

The only person who really cares about your career is you.

You can help your manager help you by helping them know what you do. Sometimes this feels like an undue burden. Surely your manager can keep track of what you’ve accomplished on their team. And some do know some of the stuff you’ve done, some time.

But what you want is to help them know everything that you’ve done that you’re proud of. This helps them understand what a great team member you are, and also gives them ammunition to fight for resources (money, projects) that you deserve.

One place to put this information is in your LinkedIn profile (more about my opinion on LinkedIn). Of course, make sure you don’t reveal any company secrets (projects, launches, technologies) in this.

Another alternative is an internal brag document. Julia Evans has written a great post on writing one. This outlines one way you can help your manager (and yourself) keep track of all the great work you’ve done. It can be far more detailed since it is internal and not limited in length.

It’s not just limited to project accomplishments. You can build a bigger story. From the post:

In addition to just listing accomplishments, in your brag document you can write the narrative explaining the big picture of your work. Have you been really focused on security? On building your product skills & having really good relationships with your users? On building a strong culture of code review on the team?

I haven’t written one of these (although you could consider my blog somewhat of a brag document, I suppose. Yet another reason to start a blog). But having some kind of record of your accomplishments that you can share with your manager will help them help you.

Sincerely,

Dan

Personal projects make you a better developer

Dear new developer,

I firmly believe that having a side project makes you a better developer. This kinda sucks, because when I get home from a day struggling at the office, I don’t want to sit in front of the computer for yet longer. But if you can make it happen, even if it is only an hour a week, you’ll learn so much from a side project.

This post covers some other great reasons for you to start up a personal project.

From the post:

[A side project] is like when you let kids color outside of the lines [because no one else need ever see the code]. You start to think and see things differently. Plus you get to try different things in the process. You could start learning a new framework and realize that you don’t like it and stop immediately. There aren’t any consequences in your personal projects.

I found a side project to be a great place to experiment with different tools and languages that I may not have used during my day job. For instance, I was able to play with a recommendation engine and a static site deployment tool.

The post also ends with tips on picking a side project, but my advice is: pick a problem that matters to you. When you are trying to find time to work on something between all the other demands on your time, you have to really want to do so, and the only way I’ve found to do that is to be really excited about the problem space.

Other tips from me:

  • You can start with a blog. If you don’t want to write code, you can just write prose. That can be a fun way to explore new technologies or business domains.
  • Don’t be pragmatic (unless you want to commercialize the project). At work you need to walk the line between beautiful code and delivery. Side projects let you focus on beautiful code.
  • Don’t be afraid to let the project go. I have done this. It’s painful, but if you aren’t enjoying the project, let it go. I’ve found a commitment of at least six months is good to ‘get over the hump’ that I encounter beginning anything, but if you’ve been doing a side project for at least that long and you find yourself avoiding it, give yourself a break of a month or two. If you aren’t interested after the break, let it go.
  • If you don’t have time for something yourself, find a project where you can help. Ask around on local slacks or meetups or check out codeforamerica.org for ideas.

The post I mentioned is worth a read in entirety.

Sincerely,

Dan

How to be a successful junior engineer

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.

and

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.

Sincerely,

Dan

Three Tips for New Developers

Dear new developer,

I ran across this post with three tips for new developers.

The tips were:

  • Develop broad expertise
  • Work in application support
  • Hone your interpersonal skills

This especially resonated with me. Note that the javascript frameworks indicate this article is a bit dated; I’d substitute React, Vue and Angular for jQuery, MooTools and Prototype, but the premise is the same. You can’t make an intelligent choice between alternatives if you only understand one of them.

To sum it up, I advise new developers to work with multiple platforms. For instance, C# developers should get familiar with truly open source alternatives like PHP or Ruby, and web developers should get to know more than just one JavaScript framework like jQuery — they should get to know MooTools, Prototype, and more. Another consideration is that doing consultant work often means working within the client’s environment and technologies, so the ability to dive into new (or new to you) technologies is a must.

I can’t argue with any of these. From a high level view, when you are beginning your career, you want to learn as much as possible from a variety of perspectives. This will inform your career in the future and let you make decisions from a position of knowledge, rather than assumption. So spread your wings. When I was a new developer, I worked all up and down the software stack, from server management to database administration to front end development. And I learned what I was both good at and enjoyed.

The other thing to be aware of is that you are more likely to be hired for potential rather than knowledge early in your career. That means that if you step into, say, an application support role and then want to move out of it, you can focus on what you learned or how you improved the company, rather than what you did. A senior application support developer who’d been working in that field for ten years would have a harder time making that pitch than a newer developer.

Finally, improving your “soft” skills of communication and team work will pay dividends in the future. Rare are the developer jobs that are 100% (or even 80%) focused on coding. Defining the problem is often the hardest part of the development process, and it certainly has the most value. (Which would you rather have, the perfect solution to the wrong problem, or the 80% solution for the right problem?)

The entire post is worth a read.

Sincerely,

Dan

Things learned the hard way

Dear new developer,

Sometimes you only learn through experience. This post catalogs 30 years of experience. As I read this, I nodded my head often.

Good points include:

Be ready to throw your code away

A lot of people, when they start with TDD, get annoyed when you say that you may have to rewrite a lot of stuff, including whatever your already wrote.

TDD was designed to throw code away: The more you learn about your problem, the more you understand that, whatever you wrote, won’t solve the problem in the long run.

You shouldn’t worry about this. Your code is not a wall: if you have to throw it always, it is not wasted material. Surely it means your time writing code was lost, but you got a better understanding about the problem now.

and

A language is much more than a language

A programming language is that thing that you write and make things “go”. But it has much more beyond special words: It has a build system, it has a dependency control system, it has a way of making tools/libraries/frameworks interact, it has a community, it has a way of dealing with people.

Don’t pick languages just ’cause they easier to use. Always remember that you may approve the syntax of a language for being that easy, but you’re also enabling the way maintainers deal with the community by choosing that language.

and

Don’t mess with things outside your project

Sometimes people are tempted to, instead of using the proper extension tools, change external libraries/frameworks — for example, making changes directly into WordPress or Django.

This is an easy way to make the project unmaintainable really really fast. As soon as a new version is released, you’ll have to keep up your changes in sync with the main project and, pretty soon, you’ll find that the changes don’t apply anymore and you’ll leave the external project in an old version, full of security bugs.

and

Companies look for specialists but keep generalists longer

If you know a lot about one single language, it may make it easier to get a job, but in the long run, language usage dies and you’ll need to find something else. Knowing a bit about a lot of other languages helps in the long run, not to mention that may help you think of better solutions.

The whole thing, though long, is worth a read.

Sincerely,

Dan

Assume Positive Intent

Dear new developer,

I enjoyed this post from Rick Manelius (who also did a guest post a few months ago) about assuming positive intent. From the post:

Chris [a client] could have crushed me, and yet he didn’t. In fact, he did the exact opposite and taught me an incredibly valuable lesson. Amidst the bickering on one phone call, he asked his colleagues to stop this behavior and to assume positive intent instead. He went on to describe how this is a philosophy he’s adopted in his personal and professional life as a means of being more efficient, effective, and solution focused. After all, approaching any situation with the opposite mindset results in wasted time and energy. Assuming negative intent means you’re spending lots of time second guessing everyone’s motivations, being combative instead of collaborative, and slowing everything down by having to update contracts meticulously instead of going off of a handshake.

In general, assuming positive intent makes your life better at little to no cost. There are places where it isn’t appropriate (and Rick covers some of them). But having an operating assumption that everyone is trying to do the best they can is a good way to view the world. It’s a lot more fun. It leads you to partnership (rather than strife).

Sometimes I struggle with this. As developers, we spend a lot of time thinking about how things can go wrong. Sometimes I’m not as trusting as I should be. But when I’ve assumed positive intent, I am rarely wrong.

Sincerely,

Dan

Advice to New Developers From A Googler

Dear new developer,

Monica Dinculescu, who works at Google, has some good advice for new developers. I don’t agree with everything she says (ah, the cacophony) but some of it definitely resonates. She has a unique approach to an AMA (ask me anything) using GitHub issues.

My favorite answer was to this question:

Sometimes I feel like I’m not good enough to become a professional software developer

I think you’re putting too much pressure on yourself! Feeling like you’re not good enough is so standard in life it even has its own name: impostor syndrome. All the developers I know, myself included, have on countless occasions thought everyone else was better than them and they just accidentally got lucky. We’ve all been stuck on a problem for days, only to randomly discover a solution after a while, out of nowhere. I find stepping away from it or talking to people helps a lot! I also do this super annoying thing to my co-workers where I explain to them, out loud, the problem I have, but by explaining it to them I end up thinking about a solution. (this also has a name, it’s called rubber ducking!). Anyway, it just takes time and practice to become confident!

We all have difficulties. I remember lying down in my home office, struggling with one of the hardest problems I’ve ever faced (it was how to update a partial recurring reservation for a piece of equipment if the room reservation changed), and thinking “there’s no way I can do this”. I also remember interviewing in March of 2018 and feeling like “man, I am so out of date and useless”.

The joy of technology continually evolving is that I get to learn all the time. The downside is that I feel continually out of date. Chances are you might too.  Remember, if it was easy, we would have automated it.

I hope you enjoy all of Monica’s advice.

Sincerely,

Dan

What is HackerNews’ Best Advice to New Developers

Dear new developer,

I have previously written about joining an online tech community. My personal go to right now is Hacker News. I find it has a nice mix of tech, startup/business and other interesting content for me.

Here’s a thread from a few months ago with advice for junior developers. Here are a few of my favorite pieces of advice.

Lots more good stuff, including hundreds of other comments. Worth a read.

Sincerely,

Dan