DEV Community: Dan Moore

Make the ask

Dan Moore — Mon, 28 Dec 2020 17:55:00 +0000

Dear new developer,

I’ve been surprised by how often I get a response from people I consider “famous”. A few examples.

Brad Feld, a well known venture capitalist, was willing to do a sixty minute AMA for the Boulder Ruby group. (If you want to watch the video, it was recorded.)
I asked a question of Patrick McKenzie years ago about whether I should write a book about testing ETL jobs with Pentaho Kettle. (Short answer: no.)
The guest posts on this blog.

How can you get help from someone prominent? I’m going to assume that you have someone in mind who you want to ask a question or otherwise get help from. Let’s say you are working on a post about React and you want someone to give it a review to make sure you are on the right path.

Find out more about the person. This involves some research, because you want to ask them for help on a topic they are interested in. Many people have profiles online, so review them to tune your “ask”. Google plus social media is your friend here. You don’t have to do exhaustive investigation, but if you can tune your question to their interests, you are more likely to get a response. It can also really help if you reference anything they’ve shared that is relevant to the question. If they recently posted about Redux and how it is awful, mention that you’ve read it and make an intelligent comment about their argument.

Next, get their contact info, or find it. So you need to do some more research. Lots of people make their email addresses known; that’s a good signal that they want to respond to email. I’ve had some luck with Twitter direct messages, Slack DMs, and LinkedIn messages. I’ve not had luck with public outreach (@ing someone on Twitter, for example). Find out how this person responds to others. I haven’t run into this, but I suspect there are certain people for whom Youtube comments, Tiktok messages, or Twitch DMs are the best form of contact.

Interact with this person before you make the ask. Follow them on Twitter. Share one of their posts to an online community. Comment on their blog. If they write a newsletter, subscribe to it. Even better, respond to one of their newsletters; even if someone has 10,000 subscribers, the number of email replies they receive is for each email is nowhere near that number. If you respond with a cogent comment, you’ll begin to build a relationship with them. Put in some work and you’ll also have a better idea if they are even the right person to ask.

Make sure your request is reasonable. Asking for feedback on your post is fair. Asking for 30 minutes of face to face video chat to discuss ideas is less so. Requesting someone promote your post to their followers is lame.

When you make the request, make it easy for them to both understand what you are requesting, the timeline, and the means of fulfilling the request. Here’s a good request:

Hiya ,

Would you be interested in reviewing my blog post about React deployment strategies? I have a blog focused on React front end development.

I was thinking that something on this topic might be up your alley. I saw your rant on Redux on Twitter and thought it had some great points. But one thing I wasn’t clear about: Redux sucks, but what is the alternative?

I’m looking to get this blog post published in the next week. If you are interested, I’ll send you a google doc (unless you would rather some other format; let me know). If not, no worries, and thanks for sharing your thoughts on React! I have learned a lot.

Thanks,

Dan

In this note, I have a single, reasonable request. I outline the timeframe; this makes it easy for the recipient to determine if they can possibly fulfill it. I let them know that I know who they are and their opinion on this technology, as well as that I’ve actually read and understood some of their opinions. It’s also important to make it easy for people. Google docs work for a lot of people for reviewing documents, but not everyone.

What a note like this does is encapsulate everything that this person might need to know about the request. There’s no back and forth about when the review would need to be finished. This makes the decision easier, which is what you, as the asker, should aim for.

Pick people at the right level of prominence. Don’t ask the creator of React to review a basic blog post. But if you saw someone speak at a local meetup about React, they’d be a good choice for this request. If, on the other hand, you’ve written an in-depth piece about the performance of React deployments in various scenarios and haven’t seen anything else like it, that might of more interest to someone more prominent, possibly even the creator. As long as you are thoughtful in your request, asking prominent, even famous, people is fine. I’ve been surprised at who has replied to my requests.

Next, follow up once or twice, but don’t bug them. The more prominent the person, the more they are pinged. (This is another reason to ask someone less prominent; they’re more likely to respond.) I always follow up a week later. Give them plenty of chances to say no. I always like to say “feel free to tell me to buzz off if this won’t work for you now.” But don’t give up after sending just one message; we all deal with overflowing inboxes. Patrick replied in 24 hours; Brad responded quickly but it took months to have schedules line up. If they say no, you can thank them, ask for a referral to someone else who might be able to help, or ask if you can follow up in a few months.

Finally, if they say yes, make sure you follow through on the request. For the React blog post example, make sure you send them the google doc, incorporate their feedback, and publish it. Send it to them with a note of thanks after you’re done. This completes the loop and lets them know you didn’t waste their time.

Asking someone prominent to help you out is not as hard as it sounds. Make sure you do your research, make a thoughtful request, and follow up. Not everyone can help, but some definitely will.

Sincerely,

Dan

Always leave the code better than you found it

Dan Moore — Mon, 23 Nov 2020 15:16:00 +0000

Dear new developer,

I’ve spent a lot of my time maintaining working code. I think that is more typical of software developers than working in greenfield development. Yes, there are definitely jobs where you are writing more new code than maintaining, upgrading, bug fixing and improving old code (startups without product market fit being one, consulting being another) but in general code is expensive and folks want to run it for a long time.

Often you’ll jump into code to fix a bug, investigate an issue or answer a question.

When you do so, improve it. This doesn’t mean you rewrite it, or upgrade all the libraries it depends on, or rename all the variables.

You don’t need to transform it.

But you should make it better. Just clean it up a bit. Doing so makes everyone’s lives just a bit better, helps the codebase in a sustainable way, and assists the business by making its supporting infrastructure more flexible.

What are some ways to improve the code when you are in it?

Document

Whether that is a comment that explains something tricky, a larger piece of documentation external to the code which explains how to interact with it, or fixing a typo, trustworthy documentation is key to interacting with code. This is a good way to start improving a codebase because it has minimal impact on the actual code. Therefore it is low risk. But if you’ve ever had a great comment explain a confusing bit of code, you’ll appreciate the time this effort can save.

You can also help documentation by removing old, crufty docs. If you see a comment that doesn’t apply, remove it. If there’s cut and paste documentation which doesn’t apply, get rid of it. That cleans up the code for the next person to come along (who might be you.

Write a test or improve a test

Tests help you write maintainable, extensible code that others can change fearlessly. If you run across code that isn’t tested and you have time and the supporting framework to write one, do so.

Even if it tests simple functionality such as “can I instantiate this object” or “how does this function react when I pass it two null values”, an additional test will help the robustness of the code.

Refactor it

This is one of the most flexible improvements. Refactoring code can range from renaming a variable to be more true to its nature to an overhaul of an entire module. Start small and don’t get wrapped up in perfection. Make the code clearer in intent.

It’s easy with refactoring to get wound around an axle and make too many changes and end up with broken things. Timeboxing is one technique I use to avoid, or at least minimize, my tendencies toward this when refactoring. If all I have is 30 minutes, I’ll make my changes smaller in scope.

Upgrade a dependency

It’s sometimes a winding path, but upgrading your dependencies regularly is a good way to maintain the code. I remember working in a fork of struts. It was an important application for the company, but we didn’t spend the time upgrading the dependencies, because it was too painful. Eventually, parts of the code became harder to update. The entire application couldn’t benefit from newer technologies and paradigms because of the older dependencies holding it back.

It never feels good to spend time updating a dependency; to me this always feels like running in place. But if you don’t do so, eventually dependencies will end of life and you’ll be forced to update. That’ll be even less pleasant.

All of these actions not only help others because they improve the quality of the code, they also provide examples to other developers on how to do so. For example, it is far easier to write the second test in a suite than the first. You can cut and paste a lot of the setup code and tweak only what is different. The first bit of documentation will inspire more.

Code isn’t everything, but it is an important work output. Whenever you touch it, you should strive to leave it in a better place that it was before you did so.

Sincerely,

Dan

Save off context

Dan Moore — Mon, 16 Nov 2020 16:37:00 +0000

Dear new developer,

A key part of software development is being able to pick up where you left off. You are going to have interruptions during your day, and you want to be prepared for them. Whether you took a break to rest your eyes, stepped away for lunch or have left for the day, you’ll want to capture the context of whatever you were working on.

This is especially true if you are being interrupted in the middle of the day to help a teammate or go to a meeting. These tasks are crucial to being a good team member, but often halt progress on a technical problem.

We all have to handle this type of timeslicing, but it can be difficult to remember where we were just before we stopped. Oftentimes if you are building or debugging something, you need to remember many small bits of knowledge: how pieces of a system fit together, what that blog post recommended, what tasks remain to be done.

When someone says “Hey, gotta sec?” a lot of this knowledge gets evicted from my short term memory.

It’s worth taking a minute or two and capturing the most important pieces of information so that when you return to the task, you can jog your memory easily.

The first thing I do is prepare to make time for this. If a co-worker pings me on slack to see if I have a second, I’ll reply when I see it with “sure, give me a few minutes, please”. Side note, I am a big believer in turning off notifications for slack, email and anything else. I always provide my teammates with my cellphone number and ask that if there’s anything urgent, they contact me there. (Haven’t been called yet.)

When you know an interruption is impending, plan for a context recording buffer. For example, if I have a meeting scheduled, a few minutes before the meeting, I’ll stop what I’m doing to capture the context.

Next, use that time to record what you’ll need to pick the task back up. I like to do this in a few different ways. I sometimes write things down in a paper notebook. This is great because it is free form, portable, works when I’m away from the computer, and quick. However, my handwriting is atrocious and I’ve definitely peered at notes I’ve written trying to decipher them.

I’ll also open up a text document and write down a couple of lines of context. These could be tasks I need to undertake, something I need to research, someone I need to talk to, or something I know is half working and needs to be looked at. I often do these in standalone files, but have also put them in comments in the code as well. I usually save these off, just in case my computer crashes. I could do this in a Google doc or slack message to myself, but find that a local text file is durable enough.

You can also capture this context in a more formal manner, by writing a failing test. That way, when you return to the problem, you can re-run your tests and move right to the work in progress. This is great if you are in the middle of code, but doesn’t work so well for other types of knowledge.

Another formal way to capture the context of whatever task you are doing is to use a checklist. Write it initially, modify it as the task progresses, and keep your progress up to date. If this is a complicated, multi day task, I’ve found a checklist to be useful, but if it’s an hour long task, I find the overhead of keeping the checklist up to date outweighs the benefit I receive.

These notes, by the way, aren’t designed to be your knowledge base. They don’t need to be authoritative. You aren’t going to consult this later. This isn’t full fledged documentation, these are scrawled notes which will be tossed as soon as you pick the task back up. So don’t stress over capturing everything in a way that someone else could use. Doing so will take too long for the value you’ll get.

Now that the context of your current task is saved off somewhere more durable than your poor neurons, take care of the interruption. Help that teammate. Go take that walk. Attend that meeting. Head home for dinner.

When you return, whether in 15 minutes or after a week vacation, return to the flow as soon as you can.

Re-read your notes, re-run your tests, review your checklist. And get back to it.

Sincerely,

Dan

How to say I don’t know

Dan Moore — Mon, 02 Nov 2020 18:13:00 +0000

Dear new developer,

The honest truth is that you won’t know everything. No one does. The CEO, CTO, the team lead, that really smart senior developer on your team, none of them know everything. In fact, I bet if you asked any one of them if they’d been stymied in the past week, they’d reveal that yes, they ran into something they didn’t know how to do or how to approach.

Encyclopedic knowledge isn’t a good goal. You need to know how to figure things out. But when someone asks you “can you do X?”, you need to be prepared with the right answer, even if you don’t know how to do X. For example, I was tasked with setting up a static IP for a heroku application. I didn’t know how to do this. Rather than say “I don’t know how to do that”, I said “let me do some research and get back to you.” I also asked about deadlines and how high a priority this was.

I did some research, read some docs and came up with a proposed solution. I discussed it at standup with my team, including my boss, and we came up with a path toward implementation.

When you don’t know something, and someone asks you about it, there are a few things you must do.

First, you should tell them you don’t know. They might have some clues for you, or pointers to documentation. These can all accelerate your ability to do what is asked of you.

Depending on the situation, they may assume you know, based on their experience. For example, I work in the authentication space right now, with standards like OAuth and OIDC. When I first started, I had to ask what every piece of jargon meant, but after a few months I got up to speed. Now when I talk to other audiences, I need to be careful not to use too much jargon or assume what others know. One favorite technique I use is repeating back what someone said: “Can I repeat back to you what said to make sure I understand it? What I heard is that the OAuth code grant redirects to the client application after the user authenticates. Is that right?”

When you say “I don’t know” don’t stop there. Say “I don’t know, but I’ll find out.” Again, they may point you in a direction, but by adding that second clause, you indicate that you’ll solve this problem. You should also ask about timeline and priority if that hasn’t been communicated (by story points, a task tracker or in some other fashion).

Finally, do what you say you’re going to do. Find out what you didn’t know. Don’t be afraid to ask questions of your team members, spend time on the internet searching, set up your dev environment and tweak settings, brainstorm, get frustrated, and write down hypotheses that you can test out. All of these are techniques I’ve used in trying to figure things out.

Saying I don’t know, honestly, with a plan to remedy your ignorance, is a key part of being a software developer.

Sincerely,

Dan

Plan first, then code

Dan Moore — Mon, 19 Oct 2020 14:09:00 +0000

Dear new developer,

I thought this article was worth sharing, as it is a relatively inexperienced developer talking to newer devs. But as I read it, one piece of advice stuck out and is worth emphasizing.

Plan first, then code

Roberto Hernandez

This is fundamental. Unlike, say carpentry, where planning is critical because you waste material if you don’t, coding sometimes feels like you can “just start.” After all, if you make a mistake, you can delete the code and start over (as long as you’re operating on your own development environment, not production). Seeing what you’re building is satisfying, both to you as a builder and anyone else you share your work with.

However, “just starting” is a recipe for waste, if what you start is writing code.

The first thing you should do before writing a single line of code is understand the problem. Depending on the size and scale of the problem, confirming this understanding could be as simple as repeating the request back to the person ho made it: “so what you are saying is you want me to change the button text to blue” and thinking through the ramifications: “that will work on form A and B, but what about form C?”.

Or it could be as complicated as writing up a specifications document with the proposed changes and architecture, getting feedback on it, running it by the appropriate people or committees, and getting sign-off from stakeholders, including executives and customers.

Then, after you confirm you understand the problem and proposed solution, plan on how you are going to execute against it. For a small problem, this could involve starting immediately by writing or thinking of a list of tasks to do, though often you’ll want to add it to a todo list or calendar to ensure this task isn’t lost among the sea of other tasks you have. For a larger problem, there may be cross team coordination required, so: meetings and documents.

After you understand the problem and have a plan for how to accomplish this goal, you can begin writing code.

Avoid jumping in and writing code because the time to feedback is long. Compared to what? Compared to text, images or meetings. These are so much easier to iterate. If you write some code to solve the wrong problem or address it in the wrong manner, you’ve used more time than you would have if you’d talked through the problem.

It is also harder to communicate concepts with code, especially with non technical colleagues. Even with fellow engineers, a diagram or conversation is an easier way to explain ideas than written code. I’ve often whiteboarded a solution in a fraction of the time it would have taken to prototype it. Code is more precise and you can’t handwave a problem away, but there’s lots of chaff around the germ of the idea in many code bases.

There are times when writing code is the right way to start, though. This is called prototyping and if there’s no way to gain an understanding of the problem by reading, learning, discussing or otherwise approaching it, write some code to explore it. However, be prepared to throw this code away, as it will be the equivalent of a hastily scratched note on a napkin.

I do want to emphasize that this understanding and planning process doesn’t always have to be heavyweight and formal. In fact, for smaller tasks, you may internalize this process and not even realize you are doing it.

Next time you are working on a small task, take a moment and think about how you break it up into even smaller bits of work: “ok, I need to add this form. Therefore I need a model and a view too, and what are the methods I should add to validate the input?”

You don’t need to produce documentation and artifacts for every decision, but you would do well to at least in your own head think through the tasks and the ramifications of those tasks. This will help you look around corners and see issues that may arise because of your solution. If you do, you can modify the solution, again, before any code is written.

Sincerely,

Dan

How to make a move to a related occupation

Dan Moore — Mon, 05 Oct 2020 14:06:00 +0000

Dear new developer,

I’ve written before about how being a developer sets you up for a lot of adjacent professions. Jobs like:

Engineering manager
Technical trainer
Startup CTO
Product manager
Developer advocate
Sales engineer

I have either direct personal experience or have watched a colleague or friend transition to those types of jobs. I’m sure there are many that I’m missing.

I had someone ask me about developer advocacy and how she could transition into it. I gave some off the cuff advice that I’d like to formalize in this post.

Moving to an entirely different career (“I want to be a rock climbing guide!”) is a bit different, but if you are transitioning to an adjacent profession, I think there are four parts.

Google

First off, find out more about the position: the responsibilities day to day, the types of problems you’ll face, what kinds of companies hire for the position, what kind of career growth is possible, the salary ranges, the challenges.

All this information will help you make an informed decision about whether a move is what you want to do. I’d spend a lot of time researching using Google because you can do that at your leisure.

If you decide from this research that you are interested in taking the next step, then you’ll want to talk to some people already doing the job.

Interview

Reach out to people who are or have done the job, whether internal to your current employer or on LinkedIn, and ask for their time. The research you’ve done previously should leave you with some questions. For example, for a developer relations position, you might ask the following questions:

How do I find companies looking to hire devrel folks?
How much experience do I really need?
What is the split of coding vs speaking vs writing?
Person X said Y about devrel, is that true in your experience?

If you do that, make sure you have a crystal clear agenda if you don’t know them personally, and that you communicate your focus. These folks are probably busy. Don’t start off the message saying you’d like to “pick their brain” for 30 minutes at coffee. Instead say:

I’ve been researching a career transition to developer relations and I notice you’ve been doing this for a few years. I’m especially interested in your experience at and would love 30 minutes of your time to ask some questions. If you’d prefer email, happy to do that as well.

If you are still interested in this change, the next step is to try it.

Give it a try

You should now have a good grasp of what kind of day to day work is needed for this adjacent profession. Now you want to try it in a low stakes way.

Want to be a trainer? Research and give a talk about a new technology in the area you want to train in.
If you are interested in product management, see if there are user interviews that need to be done for your current work. Can you sit in on one, or run it
Devrel interesting? Write some blog posts about a technology you’d like to promote.

From your previous research, you should be able to find an easy way to practice some of these skills. You could find an open source project looking for help, ask around internally, or start/continue a side project.

Doing this has two benefits:

You can learn even more about the profession.
When you want to make a transition, you can point to this work as an example that you have the skills to do so.

How long should you do this? Ah, another example of the secretary problem. I don’t know. But you should try it a few times, enough to give you a feel.

Finally, if you are still interested, take the plunge.

The plunge

You can transition internally or by getting a new job. If you do the former, the stakes are lower and you’ll come in with your existing reputation, which will presumably help you. However, it may be tough to do if the company doesn’t really have a need for the position. For example, I was interested in developer relations, but worked for a consulting company which didn’t have a developer facing product. It would have been difficult for that company to justify a developer relations position.

If you can, though, the internal transfer is a great way to go. While every internal political situation varies, if you think one is possible, I’d talk to the manager of the team to which you want to transition and to your own manager and see what they think. Is it possible? What is a good timeline? Should the transition be blended (two days in one position, three in the other) or have a firm cutoff? What would success look like?

In a smaller company, you may have more flexibility if you see a gap. One colleague stepped into product management successfully because she saw the company needed it and no one was doing it full time.

If you don’t see an internal option, interview with other companies. Be prepared with an explanation of why you want to make the transition and how they’ll benefit from hiring you. Your research and experimentation should provide you with plenty of anecdotes to share.

Finally, one nice aspect of software development is that if you take a year or three off in an adjacent field, you can come back. The change need not be permanent. You may need to brush up on some particular technologies, but in general I’ve found you can transition back fairly easily. And you’ll be a more valuable software developer if you know about product management, how to have a one to one, or marketing automation.

Sometimes you just have to ship it

Dan Moore — Mon, 07 Sep 2020 10:45:00 +0000

Dear new developer,

For me, there comes a point at the end of every project where I’m just sick of it. I’m sick of the project. I’m sick of the technology. I’m sick of project management system. I’m sick of the code.

Sometimes, I just want to see the whole thing burn. Or better, just ship it.

Now, I think that there are two solutions to this problem, and which one you pick depends on your timeline. The first is to take a step back. Talk to a team mate. Work on something else. Talk a walk. Take an extra half hour for lunch.

This may give you perspective to help you dive back in and add just a bit more polish. That polish, which may take the form of additional UX refinement, testing, or even wordsmithing the help messages or marketing text, can help make the project shine.

That’s what I call ‘running through the finish line’ where you want to leave it all on the field. That doesn’t mean you don’t make compromises or that you won’t revisit decisions, but it does mean that you do the best you can. Sometimes to put in that final effort, you need to take a break.

The other choice is to just ship it. This is a good option when you are up against a deadline. It also helps if you know you are a perfectionist and/or afraid of putting your work out there. Nothing is perfect and if your work never sees the light of day because you can’t accept that, the world is losign out. Finally, it can help if you take that time off, acquire that perspective and know that you’re done with this phase of the work.

I just published a book. It was released on Aug 16. I’m very proud of it, but there were times when I was just plain sick of it. I ended up taking some time away from it and that helped me make sure it was the best book it could be.

When you are working through the final bits of a project, sit back and get that perspective. And then, ship it!

Dan

When do you feel like you’re “senior”

Dan Moore — Mon, 24 Aug 2020 09:43:00 +0000

Dear new developer,

Senior/experienced devs: how do you know when you've become a "good coder"? How do you assess your own skills?

— Saron (@saronyitbarek ) April 28, 2020

I thought this was a great tweet. It’s worth clicking through and reading the responses. I wrote my own tweet in response, but thought I’d write about it a bit more here.

First, it’s worth acknowledging that the term “senior developer” means different things in different places and times. Certainly the knowledge expected of a senior developer in 2020 is different than in 2010. And likewise, a senior developer at a small consulting company will probably be ineffective at Google and vice versa. I’ve written more about the various types of senior developers here.

It is also worth pointing out that a senior developer isn’t the same as being a good coder. A senior developer has that skill plus many others. So, how do you know you are a good coder? In my mind, there are three attributes:

You know your tools
You can figure out what the right code to write is
You can make the right set of tradeoffs

Let’s examine each of these in turn.

First, it’s important to know your tools. These could be low level tools like the syntax of your language or your text editor. They could be higher level tools, like an open source framework or a custom library. They could be computer science focused tools like a parser.

But you need to know these tools and what are the right ones to apply to solve the problem at hand. Otherwise you’ll either be re-inventing something that has already been done or trying to apply the wrong tool to a problem (much like using a saw to hammer a nail; can be done, isn’t pretty).

Next, you need to figure out what the right code to write is. Even if it is no code. This means that you don’t expect to be handed a full set of requirements from some all knowing figure. It means you dig in and understand the domain. That you apply your knowledge and skills to the problem. And that you use the above tools to solve the problem within the constraints that you are operating.

For that is the final piece. Every bit of code has its own context in which it was written. The code that you write to load a CSV file one time can be undocumented and slow. The code that you write that will be executed multiple times by every application user should be polished, tested and fast. As a senior developer, I think you know that “good code” is context dependent.

You understand that context and make appropriate choices to get the job done.

Sincerely,

Dan

Seek feedback loops

Dan Moore — Mon, 03 Aug 2020 13:51:00 +0000

Dear new developer,

Feedback loops are so important. (If you’re not sure what that is, I’d recommend “Thinking in Systems”.)

These loops help systems improve. If you don’t have feedback, you’ll improve more slowly, in my experience. Why? Because you won’t know what you are doing that is good and what is garbage. It’s really hard to evaluate that kind of stuff yourself. You can do it, it just takes time and perspective.

And of course, you want to do more of what is good. Here are some kinds of feedback loops which have helped me.

tests
one to ones
public writing
being a contractor

Automated tests are a really tight feedback loop. You can make changes to code and know if you’ve blown things up. (Type systems are another tight feedback loop preferred by some.) This is helpful in many situations, including when you are debugging a problem.

One to ones are a great way to gather feedback from your manager on problems, challenges and situations that you have faced. By doing it in a one to one (rather than a one off meeting), you’ll build context and history around these. After all, the tenth time you bring up the fact you find front-end development challenging indicates that this is a pattern, and you should evolve yourself or the position to help with the challenge. When you have your meeting, make sure you ask for feedback explicitly. When you get it, avoid being defensive. If you make it hard to get feedback, you’ll get less.

Public writing, especially a blog, is a great way to get feedback. You’ll be able to put your thoughts out in public. This can be scary and frustrating; some communities are more gentle about feedback than others. But the act of writing forces you to make the implicit explicit. And sharing that knowledge is a great way to get feedback. (Even a lack of response is feedback; what you were writing didn’t resonated with the audience you shared it with.)

I think everyone should try being a contractor. First it makes you appreciative of everyone else in a business, because when you are contracting, you often have to take on roles outside of development (sales, accounting, marketing). But for the purposes of this post, contracting is a great way to get feedback from the market. You’ll learn about which skills are in demand and what organizations will pay for those skills. Of course, you can find this out as an employee, but if you are a contractor, especially a short term one, you’ll be interacting with possible hiring managers much more often than as an employee. And the feedback loop is brutal and blunt: do they hire you or not.

Feedback loops are a key way to find out whether what you are doing is working or not. Seek them out.

Sincerely,

Dan

Don’t sign anything you can’t understand

Dan Moore — Mon, 22 Jun 2020 14:55:00 +0000

Dear new developer,

I want to preface this with the fact that I am not a lawyer , so please don’t take this as legal advice. This is my experience with employment contracts and other legal adventures as a software developer.

When you are starting a new job, you’ll be confronted with a big basket of paperwork to sign. Actually, nowadays it’ll probably be a pile of PDFs. When you leave a job, you may sign a termination agreement, which again will be a lot of legal documents.

Read all of them. If you don’t understand something, ask what it means.

These legal agreements can profoundly affect your career. (Here’s an example of a noncompete causing a fair bit of legal pain.) It also doesn’t really matter what someone like your boss says when you are hired or leave–it’s the legal documents everyone signed that will control. (Often the employee handbook is incorporated by reference into your starting docs. Ask to see that as well.)

So read them and understand them. If someone won’t answer what a phrase means, seek info from someone else at the company, perhaps HR. You should, in certain circumstances such as a layoff, make sure you get the document reviewed by a lawyer who is looking out for your interests.

I have only sought advice from a few lawyers in my life, but all of them I found through referral. I’d recommend finding your lawyer that way as well. Ask family members, other professional contacts, or even people you’ve interacted with online in your area for a recommendation. A good lawyer should:

cost a lot of money–my most recent lawyer charged $475/hour
be willing to listen
focus on understanding what you want from them (for example, “is this employment contract normal”)
stick to your budget; make sure you communicate that
be local–different laws apply in different countries, states and cities
have expertise in the area and be willing to refer you if they don’t

You’ll pay for the certainty of a lawyer’s review, which is why you should check out the documents and only ask about sections you don’t understand, rather than sending them the entire document.

Now, for higher risk/return situations, it may be worthwhile to have every document reviewed. When I joined a startup as a co-founder, I had the entire agreement reviewed. But I don’t do that for my normal employment agreements or any contracts I sign as a consultant.

There are three main benefits of reviewing these agreements. (I’ll focus on employment agreements as those are by far what I have the most experience with, but realize you should read and understand any legal document you sign.) The first is that often there is scope for you to protect previous projects, ideas or side businesses. This can be as simple as listing the project in broad terms. Should you have any desire to commercialize a project in the future, doing this ensures it is not entangled with your employer’s properties.

Another benefit is that you’ll know your rights. Even if the agreement is punitive, wouldn’t you rather know, rather that discover it after you’d violated the contract? Here are things I look for in an employment contract:

Who owns what I create while on the job? As an employee, it will almost always be the employer. If you are contracting, it can vary and I know people who’ve started businesses because they had the insight to ask for non-exclusive rights to the code they were creating.
Who owns what I create while not on the job? In most cases, you should own anything you build on your own time, but be wary if the company works in a similar area, and if you use company resources to do the building. Get clear on this. (Some states, such as California, have explicit laws explaining the boundaries.)
What limits are placed on me after I leave? Do I have a non-compete, and if so for how long? How broad is the non-compete–what areas of employment are now off limits? What about confidentiality agreements? Is there anything else I need to do? One company employment agreement dictated I let them know where I was working for three years in the future.
What am I getting paid? Any salary or bonuses that were mentioned verbally should be included in written form, either in the offer letter or employment agreements.

It’s worth noting again that the verbal promises of anyone at the company are typically worth far less than the written agreement. I’ve had some employers honor verbal agreements (and those are good employers to stick with!), but typically when the rubber meets the road, what is written down is what will be enforced. So if someone says “ah, don’t worry about that clause” then simply ask if you can strike it from the document. And if someone promises you something, ask for it in writing. No need to be arrogant, but realize that if anyone in a business setting won’t put a statement in writing, getting what was promised will probably be difficult.

The final benefit of reading what you’re signing is that now that you have protected some of your previous inventions (if any) and know what you are agreeing to, you can negotiate.

The amount of leverage you have to change any of these agreements depends on how big the company is and how much you are desired. If you’re a new developer and the company is large, they probably won’t budge. If you’re a senior engineer that the hiring manager really wants, clauses can be negotiable. It doesn’t hurt to ask.

I understand that you may not feel you have a lot of power. You may have gone through a grueling interview process and may not have many other options if you don’t take this job. In that case, you don’t have a lot of negotiating power, but at the least you can know what you’re agreeing to. The earlier you can see these agreements, the better. The best is if you can see them before you turn down any other job offers.

At the end of the day, these agreements can have a large future impact on your career. They can limit who you can work for, what you can do, and who owns what you have made. Understand what you are agreeing to.

Sincerely,

Dan

Develop empathy

Dan Moore — Mon, 03 Feb 2020 13:56:02 +0000

Dear new developer,

Right now you’re probably a bit frustrated and confused. You’re learning a lot of things and you don’t really understand everything. Sometimes things click and it all makes sense, other times you’re confused and staring at what feels like a brick wall. Perhaps you just want to make things work and they won’t.

Good.

I say that not because I’m a sadist or dislike you. I say that because I hope you’ll remember the frustration you are experiencing right now. I think that will make you a better developer.

Why?

Because that is the state of 99% of your users. Whether they are a business employee or a person trying to use your app for personal reasons. They are just trying to finish a task and get on with their life. The software you are writing is the tool they are using to do that.

They don’t care about elegance of code.
They don’t care how much you love to develop.
They don’t care if you are learning and growing.

They just want to finish their job, complete their task, do their thing.

And, honestly, the tools we provide are frustrating. They’re buggy. They’re slow. The fact that they are amazing compared to what we could create a few years ago and that they are better than the alternative is beside the point.

I don’t write this to cause despair, new developer. Progress is being made. But it’s made one person at a time. Each person has to act with empathy toward their frustrated users. Understand them. Care about them.

And if you can remember the frustration you are currently encountering, perhaps you’ll have just a bit more empathy toward your end user, who is just trying to use your work product to get something done.

Sincerely,

Dan

Learn automated testing

Dan Moore — Tue, 21 Jan 2020 12:01:23 +0000

Dear new developer,

If you want to build good software, learn automated testing. Depending on your platform of choice, you may have good defaults or you may need to investigate options. But I think of a test suite as a “fat suit” for your code. Sure, your code can still “fall down”. But it will hurt much less.

Automated test code is still code, and that means that it has a cost. You need to maintain it (both with infrastructure and developer time). I worked on a project once that had so many tests it felt like when you made a small change to the code, you spent most of the time updating tests. That is not optimal, and those tests could be refactored. You should count on spending some time working on your test suite, but I do feel that things that may be red flags in production code are OK with test code (just because that is supporting infrastructure).

On the project with the many tests, we knew when things broke because of all those tests. And we felt comfortable changing complicated logic knowing that edge cases were handled.

On another project I wrote a lot of tests and any time there was a bug that came in for a particularly complicated piece of code (it dealt with payments), I made sure to write a test for that bug. That’s the biggest win: tests can save you from regressions. It is not very much fun to fix a bug and have it pop back up six months down the line. Writing an automated test will keep that from happening.

Tests are also living documentation, as long as they are run regularly. (Please set up continuous integration!). They will help new developers get up to speed on a project, since the new dev can tweak something and get instant feedback (rather than having to try to find where in the user interface to go.)

It takes a while to understand the right way to test. There are books to read, and examples to follow. My experience is mostly from “on the ground”. I favor unit testing anything that is complicated to understand or may change. I favor integration testing important pieces of your application. I favor knowing what your platform provides and leveraging that. I favor using continuous integration on every branch. But I realize that every situation is different.

A special note about UX. Don’t test UX that isn’t important. And realize that UX is often a piece that breaks and is hard to test. I recommend starting with something easier, on the backend or in pure logic. Functions that do things like split up strings are a great place to start.

The most important thing is to start. If you have a project that doesn’t have any testing, make that investment and do the first test, even if it is trivial (“can I instantiate this object?”). And force yourself to write tests even when you’re slinging a lot of code. It will help future you, I promise.

Sincerely,

Dan