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

How to learn things, fast

Dear new developer,

I enjoyed this post about how to learn. While the author toots his own horn a bit much for me, he makes some very valid points about how to learn. Most importantly, you want to learn using the best resource. What is best?

The best resource is a bit of a lie – it’s really just the one that’s best for you, given your prior experiences and the medium you enjoy. You’ll usually only know you found it in hindsight.

And, once you’ve gained an intermediate level understanding of what you are trying to learn, you should:

Stop. This is counter-intuitive, but unless you want to become a master at something (besides learning), you really just want to know everything at an intermediate level.

The whole post, “How to learn things at 1000x the speed”, is worth checking out.

Sincerely,

Dan

Help, I can’t learn/do something because it is boring!

Dear new developer,

Sometimes you have to learn or do something boring. I know there are times when I’ve had to schlep, whether that is data entry, learning a technology that I’m not thrilled about, or tediously manually replicating a bug many many times to try to debug it.

A couple of tips on how to deal with this:

  • Focus on the larger picture. This often helps me stay motivated. Why am I doing this? How is it connected to the larger goals of the organization? Who is this going to help when it is finished.
  • Notice the fun parts. You can’t, of course, only do the fun parts, but you can notice them and smile. For example, I am not really a front end developer. I find CSS to be a combination of both frustration and boredom, but there are times when I have to mangle it. I enjoy learning some of the basics (the difference between padding and margin). And it is often a chance to ask questions of  a member of my team with different strengths than I have, which is usually pleasant.
  • Automate what you can. Don’t go overboard, but you can do simple types of automation like creating a shell script or shell alias. Even just writing down the exact steps you are doing or the areas you’ve explored can be helpful. It’s helpful now to deal with the tedium (in two ways, both because it can be more interesting to write the automation than to do the work and because having the automation means you’re less likely to make mistakes) and helpful in the future in case this issue arises again for you or someone else.
  • Take breaks when you need to. Depending on your deadline, take periodic breaks. If there are other tasks on your todo list that you never seem to get to but have some value, take a break and do one of them. Remember that it is a marathon, not a sprint.
  • Depending on how long you’ve been working on learning this technology or task, you may want to stick your head up and make sure what you are doing is still needed. That is obviously not good advice if you have only been working on this for a few hours, but if it has been a few days or weeks, sometimes other priorities will take precedence. Be prepared to answer the question “well, how long do you have left?” with some level of confidence, though.

Sometimes you have to do or learn something that you find boring. Hopefully these tips will help make it a little easier.

Sincerely,

Dan

Benefits of blogging

Dear new developer,

I’ve written before about my belief in blogging as a way to sharpen your thoughts and give examples of your expertise. Here’s a post along the same lines. From the post:

People always try to find someone they can trust. You can go through a series of interviews and hope that they will figure out you are a great colleague, or you can write about your approaches and let a wider audience know that.
If you have a deep expertise in some technology, you can demonstrate it by writing deep and thoughtful blog posts.
If this technology is in demand, you will definitely get some opportunities coming your way!

And

Your views expressed publicly can be a good conversation starter.

This may come handy in any professional social context: interviews, meetups, conferences. It’s a different level on conversation when you get approached because someone likes your views.

The author then goes on to talk about specific, measurable ways that his blogging has helped his career.

The whole post, “Is blogging useful?”, is worth a read.

Sincerely,

Dan

Learn to look around corners

Dear new developer,

Sometimes you want to play out things two and three steps deep. Kinda like chess players, who think about many moves ahead, if you can consider the ramifications of your decisions, you’ll be well served.

I remember talking to someone about a software position at his company and he referred to the “original sin” of choosing a particular NoSQL database. This had ripple effects throughout the life of the company. Some were good, some were bad.

These kind of downstream effects are worth thinking about. The biggest ones are things like fundamental platform choices (Rails or Django, Java or golang, mysql or postgresql). But even smaller things can have ripple effects. I can’t count the times when I’ve said “I’ll just upgrade this one thing” and then the change just keeps cascading out.

Or if you are working on a feature definition, think through the ramifications. “We want to allow people to change their email address.” But if email address is the primary key of a table, or a primary means of connecting data across accounts, or some other invariant, what will the ripples in your system be.

And these are just the functional repercussions. There are also performance repercussions to changes, some of which are hard to test unless you are in production.

I’m not saying don’t accept changes. That way lies madness (and Fortran). Just be aware of how changes in complicated systems like web applications have a way of rippling out beyond their intended scope, and consider how to test, mitigate or handle such ripples.

Sincerely,

Dan

Schleps

Dear new developer,

I remember reading this article a few years ago and being struck by the wisdom contained therein. Code and development is crucial to building many businesses, but as developers we often get wrapped up in the code to the exclusion of other things.

I have definitely discounted the value of other aspects of a business (marketing, sales, accounting) in the past. That is a mistake, as there are many many things that need to happen to deliver value to a customer.

Doing a schlep is a great way to inexpensively deliver value to customers. It doesn’t scale, but it is far quicker to change a manual process than to change code.

From the essay:

No, you can’t start a startup by just writing code. I remember going through this realization myself. There was a point in 1995 when I was still trying to convince myself I could start a company by just writing code. But I soon learned from experience that schleps are not merely inevitable, but pretty much what business consists of. A company is defined by the schleps it will undertake. And schleps should be dealt with the same way you’d deal with a cold swimming pool: just jump in. Which is not to say you should seek out unpleasant work per se, but that you should never shrink from it if it’s on the path to something great.

The whole post, titled Schlep Blindness, is worth a read.

Sincerely,

Dan

Think about how things can go wrong

Dear new developer,

Think about the edge cases.

This is one of the primary ways you can add value. Think about what happens when things go wrong. It’s usually relatively straightforward to consider the happy path. Let’s take the example of a relatively simple ordering application. People can login, see their orders, and can change certain aspects of their orders (their address, perhaps) before a product is shipped.

Begging the question of why aren’t you using an open source solution like Magento or a off the shelf saas solution like Shopify, there are other things to be aware of.

  • What happens if the user wants to ship some orders to one address and some to another?
  • What does the user see when they login but have no orders?
  • What happens when they change their address?
  • What kind of validation is needed?
  • How do we know when a product is shipped? What do we do if a user wants to change their address but the product has shipped?

These are all edge cases around the happy path of login -> change address -> exit. But they are all going to affect the user experience, and so are worth thinking about.

I prefer to do it at the spec time, but any time to ask these questions is a good one. Otherwise, you’re either going to have:

  • the edge cases pop up and be handled poorly,
  • or developers making up the answers while coding

So, new developer, when you get a change to talk about a feature, think about the happy path, the expected path, to be sure. But also think about how things could go wrong.

Sincerely,

Dan