Tag: advice

Context is king

Dear new developer,

I put this image in almost every presentation I do.

pumpkin-boat

There are two reasons.

  1. It’s a striking picture, and funny.
  2. It reminds me that context is important. In some contexts, a pumpkin is a decoration. In others, food. In others, a frickin’ boat.

On that note, I recently posted my letter on admitting weaknesses in a shared slack. Some of the feedback was that this would be counterproductive to your career if you’re a minority or female.

Whenever you get advice, whether written or verbal, it is always worth considering the source. Here’s some context for me: I’m a white, heterosexual cisgender male. I have been a developer for 20 years. I have worked in the metro Denver area for my entire professional career. I have worked about half of my career in consulting companies and half in product companies. I have worked about half of my career as a contractor and half as a full time employee. Though I have worked for companies as large as Oracle, the vast majority of my experience is in companies with under one hundred employees.

What that means is that if you are looking to join Facebook, or if you are a female person of color, my advice may not be useful. While I still hope you find some nuggets of usefulness, some of it may be less helpful.

You wouldn’t ask a doctor for legal advice or a developer for medical counsel. It’s always worth considering who is giving you the advice and where they are coming from.

Sincerely,

Dan

Are you ready to work remotely?

Dear new developer,

Remote work is fantastic. You avoid a commute, have control over your work environment, and save money on lunches. However, it has downsides. You need a fast internet connection, you must be disciplined, over communicate and stay on task. You have to be OK with relative solitude.

My desire to work remotely has changed over time. Frankly, for my first job, there’s no way I would have been happy working remotely. I enjoyed the collaboration, the camaraderie, and a place to go every day where there were interesting people. Even now, with Slack, Zoom and other modern tools, I’ve seen some new developers have similar concerns.

I do think that 100% remote work is different than “work from home once a week” or “work from home when you need to”. 100% remote work requires a different workflow, communication mechanism and concept of availability than those other options. Both of the latter options are really about providing flexibility and showing trust. They are great, low cost benefits for any software company to provide to developers.

Here is a one question test for anyone considering remote work. You can ask yourself this question and if the answer is yes, a remote position will likely work well for you. If the answer is no, then I think you’d be happier with an onsite position. By the way, some people are never going to want to work remotely for a variety of reasons, and that is no big deal.

That question is: “Are you comfortable asking a dumb question in public?”

You must ask questions that appear dumb when you get up to speed in any new company. Developers of all levels do this. Often it’s two levels of questioning. The first is “who can help with this?” and then the second is the actual question.

In a remote company you’ll have to accept that you are “interrupting” people and/or asking questions into a Slack channel. I have observed that both of these are more difficult when I can’t see the mental state of other people (as you can in an office).

You’ll need answers. So you have to be prepared to do ask these kind of questions, in public or interrupting someone you think might have the answer, over and over for the first couple of months of your remote job. Public questions are better for the team but harder on my ego.

If that thought of asking basic questions in public makes you uncomfortable, congrats, you’re human. But if it makes you want to run away and hide, then perhaps you aren’t ready for remote work. If you are interested in the flexibility and freedom of 100% remote work, wait a few years, practice asking questions and internalize the fact these kind of questions may feel dumb, but actually are just part of the process at any job.

Sincerely,

Dan

A bunch of career advice from a new developer

Dear new developer,

This post has a lot of great career tips including how to select companies to apply to, what to do in an interview if you don’t know the answer to a question, and how to challenge yourself in a new job. This piece of advice in particular resonated with me:

Show how you think

Most interview questions are there to see how you think. So show that! Explain your thought process, draw diagrams, write out the intermediary code, explain pitfalls in your approach, etc! Be vocal, and ask clarifying questions. That’s part of being a good developer after all!

When I was hiring, especially for newer developers, I really wanted to hear how people thought through a problem. That process is important in two ways beyond actually solving the problem. The first is that it shows how you handle something tough that you haven’t encountered before (which happens almost every day on the job). It also shows an interviewer how you communicate. Since a lot of the challenge of building software is communication, learning how potential team members do it is crucial.

The whole post, “The Career Advice I Wish I Had” is worth a read.

Sincerely,

Dan

How to start blogging

Dear new developer,

I was asked about how to start blogging during the Q&A portion of a talk I gave. I had offhandedly recommended blogging as a great way to make connections and to be both credible and findable (locatable?) when looking for a job.

I started to spout off an answer using WordPress, and the questioner said “what about medium?”. And I stopped short. The correct answer is was “whatever is easiest”. I realized that this needed a bit more explanation, hence this letter.

So, the first thing to realize is that almost no one will read it, especially at the beginning. Why would you write if no one will read it? Well, to clarify your thought, to provide a written record of what you’ve done, and because, if you keep at it, Google will find it. Google is great at the long tail, so if you write something that is of interest to anyone, eventually people will find it.

Some numbers. This blog had the following stats for the first six months:

  • Sep: 8 posts/5 visitors
  • Oct: 11 posts/20 visitors
  • Nov: 6/15
  • Dec: 9/219
  • Jan: 8/221
  • Feb: 9/223

For the first month, I wrote more posts than visitors! And for the first three months, I had 25 posts and only 40 visitors. If you aren’t ready and willing to commit for a fair bit of time, your blog will become one of those sad blogs that I occasionally run across with three great posts, then one post six months later with the title “I haven’t posted in a while…” and then nothing.

Now, if that’s what you want, that’s ok (everyone can blog for their own reasons) but if you are looking for credibility and locatability, well, that kind of blog accomplishes neither.

So, commit for six months. I do this by:

  • writing out 20-30 titles of blog posts I want to write. If I can’t come up with that many blog post titles, I am not passionate enough about the topic to stick with it. Better to find out before investing the effort.
  • Watch for interesting concepts and mailing myself whenever I have a possible blog post idea. Then I can search my email when I have time to write but no ideas. (You can do the same with a spreadsheet, doc, trello board or whatever. Just capture the inspiration when you can.)
  • Make some posts easy by doing excerpts or commentary (about half of the posts on this blog are excerpts or guest posts).
  • Settle on a consistent schedule. No need to announce it, though. (Some people do it daily, for which I have mad respect.)
  • Write blog posts ahead of time and schedule them out. When the muse is present, it can be easy to jam out a few posts. When the muse is absent, it is a relief to not need write, but still be able to deliver to previously mentioned consistent schedule.
  • Realize that some of the posts will be mediocre. It is embarrassing to put out poor content. Don’t do that, but some posts will be better than others. Volume is key, and the longer you do it, the better the posts will get.

As far as the actual writing tool, use whatever is comfortable and easy. That may be wordpress.com, may be medium, may be netlify + hugo. Whatever it is, don’t let the technology get in the way of the writing. Especially if you are a developer, it can be more fun to be in weeds tweaking your blog deployment pipeline (at least, that’s really fun for me) but that will distract you from the main goal, which is to create good content.

My final tip is to share on online communities. Don’t only share your own work, but definitely share it. Which community? Well, find out where your people are. There are a lot of communities out there, whether tech specific like Hacker News, general purpose and public like Twitter, or focused and private, like the HangOps Slack. (Sharing is how I was able to break through in December above.)

Doesn’t matter what it is, as long as you are engaged in the community and the topic of your blog is of interest to the community. These communities are well aware of the traffic they can bring and are often wary of newcomers. I have gotten a few scoldings when I posted things that I thought were interesting, but were not in line with the community. That’s OK, just accept the community judgement, acknowledge the mistake, and do better.

Blogging is a great way to amplify your voice, display your expertise and share your knowledge. Set yourself up for success when you start one.

Sincerely,

Dan

On surviving your first year as a developer

Dear new developer,

This post covers some great tips on getting through your first year. It starts off ominously:

The first year as a programmer is one of the most frustrating things a homo sapien can experience. You’re thrust from the world of ambiguous human communication into the icy waters of cold, hard correctness. There is no compromise with the machine. It does exactly what you tell it to, no more, no less.

But then moves to some good advice, about advice:

There are very few absolutes when it comes to practical programming. A Technical opinions of developers are based on their experiences, the books they’ve read and the technologies they happened to work with. No one does a thorough survey of the technology landscape before declaring their support for a given tool, application or methodology.

This is so true. Everyone’s opinion is path dependent. I was a MySQL user for years and thought it was the best open source database, until a chance comment from someone I was chatting with at a meetup (see, you should attend a meetup) mentioned that PostgreSQL has transactional DDL. That is, you can alter a table as part of a transaction, and they roll it back. (Happy to report that MySQL has made progress on this, though I don’t believe they are at feature parity yet.) If I hadn’t run into that meetup participant, it is unlikely I would have learned that nuance.

Multiply that experience by the hundreds of decisions a developer makes every year based on their knowledge, their problem space and their work environment and you can see how different advice can be. And to be fair, how it can all be valid, based on context.

The post also covers ego-less coding, what to learn, and the joy of bug hunting. The whole post, “Survive your first year as a programmer”, is worth a read.

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