Admit your weaknesses

Dear new developer,

I just had a conversation with my boss. I said “Hey, sometimes I can be overly direct and it comes off like an a**hole. I’ve been told I’ve been condescending by co-workers. I’m working on being more empathetic but if you see behavior like this from me, please let me know.”

A few years ago, I wouldn’t have had the confidence to say this. I do this now because I’m aware of my weaknesses and I own them and share them.

This can only help a good manager. (If you don’t have a good manager, then you have bigger problems. I’d start interviewing.) They can help you grow and place you in situations where your strengths can shine and your weaknesses won’t be fatal.

What kind of skills might you have weakness in? There are two dimensions to think about:

innate <-> malleable
- Is the weakness innate in who you are (you are not tall enough to play professional basketball) or how you define yourself (you are simply not interested in learning enough about good design to become a designer), or is it learnable (you want to learn how to write code)?
- Far more things are learnable than we give ourselves credit for, it is most often a matter of energy and time. That said, as you get on in your career, some weaknesses may be not worth the effort to remediate. I don’t care enough about pixel placement to ever be a designer, which puts certain developer jobs off limits for me. But I have tried the proverbial full stack position a number of times. Don’t write off something until you’ve tried it.
- The more innate your weakness in a skill required for a job, the more proactive you should be in dealing with the weakness. This includes, as I did, informing your manager of your weakness and then doing some self work to determine how to improve (or if you even want to).
core to your job <-> ancillary to your job
- Is the skill you are weak in important to your job (are you supposed to be able to speak in front of people professionally and yet you have stage fright) or related but not crucial (you need to know a certain technology and you are not conversant with it, but are familiar with the domain space and have learned similar things before).
- The more core this skill is to your job the more proactive you should be in fixing your weakness–either finding a way to improve or finding a way to shift jobs.

When should you have this conversation about weakness? Not in the job interview. In the job interview you should be trying to put your best foot forward (and evaluating the job), not talking about your weaknesses. However you should consider how your weaknesses might play in to your ability to succeed in your job, which might cause you to pause in taking it.

Also, do not do this in your performance review. That should be about putting your best foot forward to move forward on your career goals (title, money, position, opportunity) as best as you can. (If you have had the conversations previously and have remediated some of the issues, that’s a fine topic to discuss because it shows growth.)

I think the best time to have the conversation about your weaknesses with your manager is after:

you have a clear idea about your weaknesses
you know how they will affect or not affect your ability to perform in the job
you have a plan to ameliorate their effects if they will cause performance issues
you have been on the job at least a month or two, and have some wins (because you overindexed)
you trust your manager

If all of these are true, then you will be in a good position to frankly discuss the weakness and take steps to minimize the impact. It’s best to do this in a face to face conversation.

If you can’t do this with your manager, at the least have this conversation with yourself. On paper or while exercising or commuting, think through your weaknesses and how they apply to your current position. You may find that your current position is absolutely suited to you, in which case, congratulations. You may find an area to work on or improve (“man, I really need to get better at listening before I talk”), in which case, congratulations. You may find that your current job is perversely lined up with your weaknesses, in which case, take a look around.

Sincerely,

Dan

A Crash Course for Your First Job in Software

Dear new developer,

This post, “They Didn’t Teach Us This” is a great read.

There’s a curious phenomenon that happens when new web developers take their first job. You’ve just gotten your CS degree or graduated from bootcamp, and you’ve spent months or years learning to write efficient code, practicing for interviews, and building portfolio projects. Finally you’ve accepted an offer, and you’re thrilled⁠—you’re now a Software Engineer™. You march in on your first day, your head held high. And then, in your first week of work, it dawns on you just how little you actually know.

To be honest, that is what this whole blog is about.

But never fear, the author has some suggestions. There are a whole number of items that matter for professional code (like accessibility, scale, and reliability) that don’t really factor into personal projects. He outlines these and a few other concerns. The author also talks about process (with git, environments and deployments, among other things):

So, what exactly happens during a deploy? To start, you’ve been working in a local “development” environment, which gives you the ability to see changes nearly instantly. However, what gets deployed to production often aren’t the exact files you work with on your local machine.

I didn’t have much process when I was starting out as a new developer, but the older I get, the more process matters to me, even when I am the only developer. It takes the complex and layers an abstraction over it, making it easier. In a very real way, the actual content of a process matters less than that all parties agree to it.

The whole article 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

Learn a Little Network Engineering

This is a guest blog post from Allan Wintersieck. Enjoy.

Dear new developer,

I realize that just trying to learn basic programming principles can feel daunting enough, but if I may, I’d recommend adding one more task to your list: learn a little bit about network engineering.

Networking underpins everything web and app developers do, since almost every web app communicates from the frontend to the backend regularly. Most developers understand the basics of making API calls and how data flows over the internet, but taking a small dive deeper will help you debug issues for years to come.

The goal is to build your underlying knowledge so that when you encounter related issues in the future, you understand enough about how it all works to intelligently tackle the problem. For example: the reason everyone complains about CORS (Cross-Origin Resource Sharing) being confusing is because it doesn’t make sense without first understanding the basic principles of networking and security.

A quick list to get you started:

Read up on the basics of routing. No need to dive into how the protocols work, but understand why it’s set up this way and how internet traffic gets to where it needs to go.
Read the basics of DNS, and understand how a DNS request is resolved.
Read a brief rundown of the OSI model. Focus on understanding one or two examples of things you’ve dealt with in the past that exist at each layer.
Review the difference between TCP/IP and HTTP, and why they exist at different layers in the model.
Read up on the basics of what a “proxy” is.

An overall analogy that I find helpful: networking is like sending mail via the postal service.

Routing is the process of putting mail in your mailbox, having a postal worker pick it up, and it eventually reaching its destination.
DNS is the process of looking up someone’s mailing address so you can send them mail.
The OSI model is a fancy name for making it clear that there’s a lot of details the postal service takes care of for us. Most people understand how addresses and mailboxes work (let’s call that the equivalent to the Application layer), but don’t really understand all the internal details of how the postal service gets your mail to its destination. All those details are the first 6 layers of the model.

With that background knowledge in place, tackle some of these additional questions to lead you to more learning:

How do CDNs (Content Delivery Networks) work?
What’s the difference between “regular” HTTP and WebSockets?
How does SSL (HTTPS vs. HTTP) work, at a high level?
What can nginx be used for?

And as a last exercise, sketch out a complete picture of a work app or side project: what DNS calls get made, what servers are involved, are there any proxies, what protocols are in use, what OSI layer those protocols exist on, etc.

I promise that spending the first few years of my career as a network engineer only slightly biases me towards learning this stuff.

Sincerely,
Allan Wintersieck

Allan Wintersieck is the CTO and co-founder of Devetry, a software consultancy in Denver that provides strategic partnership for software architecture and engineering.

Take care of your body

Dear new developer,

I don’t know how old you are. All I can tell you is that you should take care of your body. This includes tasks that all folks should do (get good sleep, exercise, get the regular checkups for body, eyes, teeth, skin) as well as some tasks specific to desk jockeys (get up, maybe get a standing desk, look away from the computer once in a while) and some tasks specific to being a software engineer (get an ergonomic keyboard).

Whatever you do, listen to your body. Take regular breaks. Buy the equipment you need. When I was young, my body seemed to be an endless resource.

It is not.

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

Speaking isn’t as scary as you think, eventually

Dear new developer,

I remember one of the first times I spoke in public. I was talking about J2ME (which was a technology for building mobile apps, pre iphone) to the Boulder Java Users Group. I threw up some slides showing the flow of data across the system, and made a joke along the lines of “sorry if this is confusing, but at least it isn’t UML”. The audience all laughed, and I went on with my talk.

Guess who the next speaker was?

Grady Booch, inventor of UML.

Doh.

Public speaking is a great way to do a number of things for you as a developer.

Raise your profile in your company and in the community. Standing in front of a crowd and talking about a topic will get you noticed. Even if it is a crowd of 10 at your local meetup.
Teach you how to educate people. The way to help someone understand something is not intuitive. Speaking gives you a chance to practice it, and that will help you in your work life, since a large part of development depends on helping other people understand what you mean.
Force you to really understand your topic. Trust me, the pressure of being up in front of a group of people will cause you to dive deeper than you otherwise would have. (Kinda like writing an ebook.)
Let you learn something new. Related to the above point, you can learn something new when you are presenting. This can either be ancillary to the topic you are talking about, or, in some cases, can be the topic of your talk.

Some tips for getting started:

Find something you are interested in. Brainstorm ideas around that. Think about cross sections: “Using javascript in marketing” or “what do SQL and devops have in common”. Both technical skills like javascript, SQL or design and “soft” skills like interviewing and communication can be good topics.
Join a meetup. Go a few times as a regular member, learn who the organizers are. Then go to the organizer and say “I’m a new developer, but I’d love to speak sometime. Do you have any slots open?” (You can also join Toastmasters.)
When you get a chance to talk, practice it multiple times, at least once in front of someone. Remember that you are likely the most expert person in the room. If possible, start off with a joke or self deprecating remark, and ask for audience participation. More tips.
Look for local conferences. Then, look for Calls for Proposals (“CFPs”) at such conferences. Submit. Don’t spend too much time polishing a submission. Submit any proposal to multiple conferences. Papercall is good for that. (I confess, I’m not an expert at this process, so this is more based on advice I’ve read.)
When you go to conferences or meetups, walk up to speakers and ask how they got started. I’d suggest avoiding the superstars. Regular speakers will still have useful advice, but fewer folks surrounding them.

By the way, it is terrifying, but many things are the first time you do it. I mean, do you remember learning to ride a bike?

Public speaking is a great way to stretch yourself, learn new skills and meet new people. Highly recommended.

Sincerely,

Dan