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

Learn To Explain Concepts To Non-Technical Users

Dear new developer,

I taught technology courses for about a year and a half, but have been teaching folks almost my entire career in one way or another (everyone has something to teach), primarily through my blog.

One thing I’ve learned over time is that if you can’t explain a technology choice in a way that a non technical user can understand, you don’t understand it. It can be very easy to get caught up in jargon. Jargon in and of itself is not a bad thing. It’s a shortcut. If I say RDBMS to another developer, they know that this is a third party piece of software which provides safe, durable, transactional data storage. (See how jargon builds on itself? “transactional” is jargon as well.) But just like if you take one shortcut after another you’re likely to get lost, too much jargon can blind you. (Or at least put you in a fog.) AWS In Plain English is a great example of how the names of AWS services are confusing and could be improved.

So, learn how to think about technical topics in a non technical way. Then you can bundle it up in jargon later, when you have a clear understanding of it.

One great way to do this is to learn to explain things to non technical users. You can do this via writing (a blog), speaking (at a meetup), or just talking to someone in your life (parents, friends) about what you do for a living. Lots of people are mystified by software and are happy to learn more about it. You can start as small as you like (“what’s a directory?”). Go slowly and try to explain exactly what you do. An example for a site I worked on is “we pull information from a couple of different sources and publish it.” (I confess, I had to write slowly and rewrite that sentence because I used jargon.)

Other benefit of learning to do this is that as you continue your career as a developer, you’ll typically spend more and more time around non technical people. These folks make decisions that affect business and software, but they won’t always understand the latter. If you are well versed in explaining technical concepts, you’ll be valued and be able to be at the table when decisions are made.

So, if you can explain something non technical, you gain:

  • clarity for yourself
  • the ability to teach others
  • influence in your organization

What’s not to like?

Sincerely,

Dan

Outcomes over output

This is a guest blog post from Mark Sawers. Enjoy.

Dear new developer,

As a software engineer, it’s easy to take our eye off the ball. The ball we really want to pay attention to isn’t the stuff we focused on in college. The ball is improving business/organizational outcomes. There isn’t a course of study or advanced degree on this, because it’s bespoke and custom to every organization.

You are on a team in your organization’s grand game to help the underserved, make money for shareholders, find some cure, save the planet or whatever its mission. A software-intensive system improves information access, automates task, entertains, etc. You pair with your business discipline in conceiving, building, testing and operating systems that advance the game.

Your real value to your organization is in improving outcomes. Not directly in how well you wield language X, tool Y, process Z. Not in how many features you add in a sprint, how many bugs you fix in one day, how much code you reviewed yesterday, how many answers you posted in slack, how many documents you wrote last month, and so on. Those are just means to an end.

Yes we need to constantly develop and hone technical skills (analysis, modeling, diagramming, programming, unit testing and others) and tool knowledge (languages, frameworks, utilities, operating systems, and more), but don’t mistake this for the end-game. Yes we should measure productivity; we do care about efficiency and throughput. But more product features, the latest tech, continuous deployment, two-factor authentication, and so on are not the goal. More is usually less, in my experience as a user. Isn’t that yours as well?

The goal is not output; the goal is outcome. The outcome is more revenue, more profit, more users, more product availability, happier users … right?

So, wait, isn’t that someone else’s job? What do you know about forecasting and measuring profit, anticipating user needs? Isn’t that on the product owner? The product manager? Marketing? And isn’t uptime the operations team’s responsibility? And finding problems the QA team’s responsibility?

You are on a multi-disciplinary team. You have at least one vital role to play on this team. Engineering is your trained discipline, and likely you focused purely on development. The smaller the company/business unit, the more hats you will wear. Yes your main contribution is technical, but in service of the bottom line. But don’t stay in your lane! Different perspectives are essential to this game. Your product owner doesn’t have a patent on designing end user features. And she may not be thinking about measuring success. Help her define the metrics and build those collection and reporting tools into the product. After you deploy a new feature, assess its success; don’t immediately move on to the next feature.

OK, so do I eat my own dog food? I try. The tech side requires lots of cognitive space, and so outcomes are easily short-shafted. Also, I have found this holistic perspective difficult to practice in large organizations. There is lots of specialization. It fragments responsibility. Incentives are set along discipline silos. My suggestion is to play your organization’s games (don’t leave that bonus on the table!) but bring your enlightened perspective as best you can.

Good luck,
Mark

Mark Sawers has been practicing software engineering for almost 25 years, as a developer, architect and manager. You can find his blog at http://sawers.com/blog and his LinkedIn profile at https://linkedin.com/in/marksawers .

Help your manager help you by owning the one to one agenda

Dear new developer,

You need to realize that your manager is pulled between two goals (this assumes you have a good manager–if you don’t have a manager who wants to help you, find a new job).

1. Helping you.

2. Helping the company for which you work.

Unfortunately, the latter takes precedence. It’s more work (because it includes helping everyone else out) and higher priority.

So what can you do? Make your manager aware of how they can help you. This doesn’t need to be done in a demanding manner, but you need to make sure you are heard. So, for instance, mention that you are exploring or have been reading about a new technology like machine learning, and really want an opportunity to use the skills professionally. Realize that you might not get exactly what you want (if you are working for a webdev shop, you won’t get a chance to build compilers). But if you don’t ask, your manager won’t know your career interests.

I like one to ones for this purpose. These are regular meetings (once a week to once a month) for a short period of time (30 minutes to 60 minutes) where you control the agenda. It’s not a status report or a troubleshooting session. Instead, it’s where you can ask questions and inform your manager.

Things I’ve learned in one to ones (all at different jobs):

  • a colleague wanted to go to clown school
  • I was managing as I wanted to be managed, not as a report wanted to be managed
  • a colleague’s spouse had a long commute and that a move was imminent

All of these were helpful to me in assessing the health of a team, planning for change and understanding the person. These are really what a manager should be focusing on.

Next time you go to a one to one, think about what kind of questions you need to ask or what kind of conversations you need to have to make sure your manager can help you. Here’s a list of topics that might help jump start the conversation.

If you don’t have a one to one, set one up. If your manager is resistant, find out why, and see if there is something less formal, but still regular, that you can set up. Maybe you just need to calendar a regular reminder to yourself to stop by the manager’s office. If you don’t have regular lines of communication with your manager then when things get tough, you’ll have a hard time having conversations that will help both parties. The trust and ease that regular contact builds is key for defusing a tough situation, or at least de-escalating it.

Sincerely,

Dan

How to market yourself as a new software developer

Dear new developer,

This post from Corey Snipes, an experienced software developer, is well worth a read. From the post:

People skills help so much. It’s hard to overstate that. I am a competent software developer, but I am really good at working on a team and that has carried me to increasingly sophisticated and interesting work my whole career.

There may be some kinds of software jobs where communication is not important. Maybe something in academia? Maybe finance? I don’t know, but every software job I’ve ever been in has fallen into one of a few categories:

  • working on a team. Here communication is important as it helps keep the team aligned and moving toward the correct goal
  • working by myself. Here communication is important because I’m talking to customers about what they need.

So I agree with Corey that communication is crucial.

It’s important to be clear about your limits but also about your potential. New developers are hired for potential. Again, from Corey’s post:

Be honest about your capabilities. Some people will say “fake it till you make it” but that doesn’t work for me and I’m no good at it anyway. I’d rather work with someone who knows their limitations than someone who thinks they know everything, and that’s the sort of person that I try to be. Figure out how to acknowledge your inexperience without making it sound like a problem.

The post is full of other good tips for folks starting out. He talks about two different places where a new software developer can deliver a lot of value: a paid position in a large software team and a volunteer position building something for a small business. I’m not a huge fan of volunteering because I feel like people should be paid for value they provide, but I understand that when one doesn’t have a track record, one needs to build one any which way. Open source contributions are a great way to do that, but this activity is less focused and a longer play than finding a local business that needs a website and just putting one together.

Another tip that resonated was going to meetups and getting out into the community, but I’ve already written about that.

Sincerely,

Dan