Category: letters to a new developer

When is it time to quit my 9-5?

This is a guest post from Pariss Athena. Enjoy.

Dear new developer,

Honestly, I don’t think there’s one absolute answer. I believe the answer depends on you and the risk you’re comfortable taking. However, I do think there are things you should take into account before jumping the gun. This is how I personally knew it was time to give my notice and take my business full time…

Everyone’s situation is going to be different. This is my story.

I announced that I was launching Black Tech Pipeline (BTP) in June of 2020. Around this time is when everyone was really riding the Black Lives Matter train, and claiming their allyship after George Floyd’s murder.

This was not why I decided to launch. Weeks prior to the pandemic and quarantine, I was constantly tweeting about launching BTP “in the next weeks.” Those next few weeks just happened to fall during a tragic time.

But these two things did contribute to the eagerness of announcing my launch:

  1. I knew my performance at work was dropping. I stopped attending happy hours, and engaging in conversation. It wasn’t because there was something wrong with the company I worked for, my focus just shifted.
    I was rightfully distracted by social media and the flooding of content surrounding the injustices happening in the Black community. Knowing the work I should be doing full time vs the work I was actually doing full time made me annoyed with myself. I wanted to just help create impact in my community. That’s it.
  2. I was pissed the hell off.

I want to preface this by saying that I know I have the privilege of already having a platform and a following. I know that contributed to the traction my launch announcement received.

I had been writing newsletters surrounding Black Lives Matter a few weeks before announcing my launch, and those newsletters gained lots of traction on social media, which gained me more subscribers. I decided to announce the launch of BTP in my newsletter, and the response to the announcement was sign #1 that I was going to be on my way out of my job.

My calendar was flooded with calls. I had 15 minute breaks in between calls from morning to evening. I was talking to employer after employer wanting to take advantage of BTP’s services. Aside from calls, I received emails non-stop. Not just from employers, but from opportunity extenders of all sorts. It was tiring but good problems to have, especially before even launching.

On top of my performance dropping at work from being distracted by the political climate, I was now also distracted by BTP’s calendar being completely booked. Having so many calls booked seems promising, but until I had client agreements signed and invoices paid, I wasn’t going to leave my job, especially during a pandemic.

Plenty of employers expressed interest. They loved the origin story of #BlackTechTwitter and how it led to me building Black Tech Pipeline. There were lots of promising words, but you can’t go off of words of interest to determine your safety net.

The way I determined my safety net was by looking at my finances with my mentor, Leon Noel. I kept in mind what I was making annually at my 9-5. I already knew what I was charging for my services so I also used that to think about worst and best case scenario. He told me to ask myself:

  1. At the very least, how much do you need to make to pay your bills on time?
  2. Are you willing to give up your typical lifestyle?

I looked at my pricing model and mapped out how many clients I’d have to have per month to get by. And not just how many clients, but:

  1. Which services would those clients have to pay for in order for me to get by?
  2. And when those clients pay me, how much money do I have left over after putting 30-35% into savings for tax time and personal savings?
  3. And if I don’t want to live a life of just getting by, how much money do I need to make, with tax deductions in mind, to live the life that I want to live?
  4. How much money would I like to make annually? What will it take to get there? Can I project that?
  5. Is it possible that I can stay at my 9-5 and balance my business at the same time?
  6. Could I potentially hire someone to help me out so that I can do both?

Those numbers and questions are extremely important and it’s what you should think about before making the decision to bounce from your 9-5.

Sign #2: Personally, time was not on my side. It came to a point where something had to give. It wasn’t fair to continue working my 9-5 when I wasn’t giving it my all because I was busy prioritizing my own business. I also wasn’t willing to give up potential clients, miss calls, and wait to reply to business emails for the sake of my 9-5.

Sign #3: Potential clients turned into paying clients. Agreements were getting signed, and invoices were being paid. That sounds dope, but that’s not enough to say you’re secure. The question is,

  1. With the money you’ve been paid + your savings (if any), would you be able to quit your job and be able to pay your bills for the next 6 months, even if you got no other paying clients?
  2. How many signed/not yet paid clients do you currently have?
  3. What’s your projected paying client rate for the next month?
  4. What are you going to do if you don’t have any new business coming in?

These are the risk questions, and you have to be very real with yourself when you answer them. The last thing you want is give yourself optimistic answers and then be left with late payments, debt, and serious financial hardship.

My personal answers: I’d be fine. I determined this by the tangible money I had been paid. I didn’t count the client agreements signed because anyone can back out of an agreement before the work begins, something could delay the process on their end, etc. I made enough to feel confident in giving my job my notice, and to continue living the life I want to be able to live. I only considered signed agreements when I thought about future business expectations: “I have {x} many clients potentially secured for {x} services, which will keep me financially stable for {x months}. I also have {x} many potential client calls lined up for the next {x weeks/months}.”

I also double checked with my mentor, and when he approved, I felt even more confident in leaving.

It was bittersweet, but I gave my notice. It was time. ✨Shout out to G2i for being the best employer I’ve worked for since entering the tech industry. Amazing culture, dope people, and doing the work of solving the broken vetting process.

Now, I don’t know what’s going to happen with Black Tech Pipeline. Maybe things are only going well right now and we’ll struggle later down the line. I don’t know, I hope not. I will do everything in my power to make this company successful, but there’s only so much that I have control over. That’s the risk. That’s entrepreneurship for ya.

If I’m being totally honest, a job will always be there. Companies will always be hiring. I know- I’m a recruiter.

— Pariss

This post was originally published at Black Tech Pipeline.

Pariss Athena is the creator of the movement, hashtag, and community #BlackTechTwitter, and Founder of Black Tech Pipeline.

Plan first, then code

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 who 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

If you’re trapped in your job, what should you do?

Dear new developer,

Perhaps you took the first job offered to you. Perhaps you joined a friend’s company, then realized it wasn’t quite what you were promised. Perhaps you joined a company as the only developer and didn’t realize you should avoid working alone.

You might feel trapped by the money, trapped because you believe you promised to stay for a year or two, or trapped by the position, without the ability to grow.

The most important thing to do is to prepare to leave. How can you do so? Here’s a three part plan.

Know what you want

First, write down what you want. You know more about what you don’t desire, but you need to have a clear path toward what you want. I’ll open up a google doc and write down all the things I’m disatisified with about the current situation I’m in. That may be people, it may be responsibilities, it may be salary, it may be situation, it may be the manager. This venting helps me get clarity.

Then, take some time thinking about what you’d change to be happier. This may require some research. You can do a lot of research by googling and reading, but you may also want to reach out to some members of your community to ask about their jobs. Hey, I said this was a three part plan, I didn’t say you wouldn’t have to do some work.

Think about your runway

Next, consider your financial situation. Do you have money saved up? Can you cut costs? Figure out your financial runway. If at all possible, save up three to six months of expenses, as that will make any transition time much much easier. The alternative may be borrowing from friends and family if possible, or the credit card companies if not.

I find that even just the exercise of looking at my expenses and income cause me to be more aware of my spending. You don’t have to wallow in it (though plenty of people swear by living on a budget); rather the goal is to set yourself up for success should leaving a job turn into a longer period of unemployment than you planned for.

Reach out and interview

Third, interview. Find companies who you are interested in based on the previous thought and research, and apply. Look on the company website, but don’t apply through it. The best way to apply is to hand your resume to someone already at that company. I find applicant tracking systems to be mainly good at weeding me (and others) out. Use LinkedIn to find people you know at the company. This also lets you ask them about the company culture and the job. Lots of companies, unfortunately, have job listing pages that may not reflect current needs.

If you don’t know anyone at the company, see if you can start. This includes following people on Twitter, watching speakers from the company, and connecting on LinkedIn. Please please, if you connect to someone on LinkedIn, write a quick note: “I was just watching your presentation on Kotlin and wanted to connect with more people in the community.”

Don’t be transactional about any of these interactions; you’re trying to learn more about the position and company, but you also want to provide value to the other person. How can you do so? I dunno, every situation is different, so ask.

I also use a spreadsheet to track all my applications, including contact info, links to the the job, and notes. I always have a ‘follow up date’ column where I can put in when I should reach back out again. It is hard when you are in the throes of the job search, but remember that usually finding and hiring candidates is just one part of the hiring manager’s job, and so you might slip between the cracks. Take control, send regular follow up emails, and you can avoid that fate.

If you do get an interview at a company you like, this should give you some great information. How prepared did you feel? How competent? Did you crush it or did you flub the interview? By the way, flubbing an interview is never fun, but when you already have a job is about the best time to do so.

What was the reaction of the interviewer and the company? You may not get as much information as you want (I never do) but you’ll get some feedback. I like to update that spreadsheet with whatever I learned: was there a question I didn’t answer as well as I could have? Was there a technology I need to brush up on? Do I never want to interact with that company again? All good data.

Consider your situation

Now that you’ve have prepared with your wants, your financial situation and gotten feedback from the hiring market, you can reconsider your situation. Does it seem better now? Or are you still feeling trapped. Sometimes popping your head up and looking around at other opportunities can actually make you happier where you are. Other times it reinforces your desire to move on.

If the former, go to your manager with a concrete set of changes you’d like. The amount of work to put into this depends on the scope of the changes. If you’d like more money, justify it with the value you are providing and how your salary compares to other like positions. If you want to spend more time on a different project or technology, make sure you understand how that would benefit the company, not just you.

Be flexible. If you want mentoring but there’s not money to hire a senior developer above you, ask if you can attend conferences or hire a senior developer on an hourly basis to bounce ideas off of. I had an acquaintance who regularly hired people on Upwork to consult with when he ran into thorny technical issues.

The point is to inform your boss, in a polite way, of any changes which would make you happier. Know that there might be no time or budget for some of them, but I guarantee that you’ll have a higher chance of making something happen if you present reasoning why both you and the company will benefit. Bosses don’t read minds.

If it is time to move on, keep interviewing and when you get an offer, leave professionally. Give two weeks notice (or whatever is typical in your country or spelled out in your employment agreement). Connect to co-workers on LinkedIn. And head off to your next adventure.

Sincerely,

Dan

How to make a move to a related occupation

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 <startup> 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.

The Code Will Never Judge You

This is a guest post from Lorna Mitchell. Enjoy.

Dear new developer,

Recently, I decided my seven-year-old niece was old enough for her first programmable device. She has done a little bit of Scratch with me, so I bought her a BBC micro:bit (a very simple programmable device, with a web editor and USB connection, some buttons and some LEDs) and showed her how to get started. Then I said to my sister (whose child this is) “the tears are all part of the software development process, so try not to worry when it happens!”. However many years down the path I am myself, coding is still a rollercoaster and there are some downs as well as some ups.

One thing that makes software development more difficult is wondering if you are really cut out for this. It’s so easy to feel like you are doing software “wrong” in some way. Spoiler: there really isn’t a right way, it’s part art as well as part science. Keep the user in mind and apply the technology the best way you know how; you’ll go far.

Some days it doesn’t feel like it’s going well and you may wonder if you will ever be really good at your chosen profession. On other days, or perhaps overlapping days, other people will think you’re not cut out for it either. Maybe you think your skill set isn’t a good fit (it is), or that you don’t really look like a software developer (you do). It is very difficult to help other humans who have already decided that they don’t quite believe in you. From extensive field testing, I have found that almost none of them ever change their mind.

In fact, this is much less important than it seems. If you don’t understand the pop culture that inspired the bot/server names, you didn’t play the same computer games or watch the same films (I’ve still never seen Star Wars), that doesn’t impact on what you can be. For minorities of all stripes, not sharing the supposedly shared culture can really make you doubt yourself. That’s a human reaction, don’t feel bad for feeling your feelings. If you want to be a person who does play those games and watch those films, then go for it.

But if you are just there to be the best software developer you can be, then let the other things go past you, and focus on the things you really do want to learn from, and share with, the crowd. I think most of what I know about text editors, information security, and leadership I learned from colleagues or conference encounters. It took me far too long to realise that software developers do look and sound like I do, and my own interests and hobbies are no less valid than anyone else’s (I also know more very technical humans with yarncraft hobbies now).

The code will never judge you. You show up, try things out, keep learning, keep iterating. That’s how software is made. It isn’t made of what other people thought you could do, it’s only made of what you did do, and for that you need to show up, and do.

— Lorna

Lorna is based in Yorkshire, UK; she is a Developer Advocate at Vonage as well as a published author and experienced conference speaker. Lorna is passionate about open source technologies and sharing knowledge, code and experiences with developers everywhere. In her spare time, Lorna blogs at https://lornajane.net.

You’re gonna be OK

This is a guest post from Jerome Hardaway. Enjoy.

Dear new developer,

So, you’re in the office, learning a million things a minute that you were never exposed to. Everyone around you seems super competent and you don’t want to take time away from them, but you have no idea what you’re doing. You feel like you should probably be a janitor instead of working on a million dollar web app. I’m here to tell you, you’re wrong.

Every person who seems competent has felt like you or still feels like you do, they are just better at hiding it. I know people who have been doing this work for years and feel silly at least once a week. Hitting your head against the tech wall is a rite of passage here and normal and whether they tell you or not, we have all been there. We have all either accidentally taken down prod, nuked the repo, felt lost, accidentally ran up the AWS bill, and just straight up sucked at this job. So long as you focus on having more good days than bad, you will be fine. More than that, you’ll do great, so relax cause we are all rooting for you.

— Jerome

Jerome Hardaway is a Developer Advocate at Quicken Loans and Executive Director at Vets Who Code, Where they help veterans get jobs in software by teaching them how to program for free.

You’re probably going to want to quit

This is a guest post from Mia de Búrca. Enjoy.

Dear new developer,

You’re probably going to want to quit.

The very qualities that make writing software appealing can also make it frustrating beyond belief. You’re headed down this path because you like to be challenged, to learn and grow. However, facing new harder problems day in, day out can take its toll on your morale. And keeping up to date, familiarising yourself with the breadth and depth of topics in this domain – it can be overwhelming. But if you’re reading this it’s likely you’ve already felt the deep satisfaction of writing code to be proud of, so I hope that by sharing my experiences, from early in my career and from a few weeks ago, you will be motivated to push through and keep enjoying the journey.

The Import

One of the first times I nearly quit was a few weeks into my first role as a dev. I was fortunate enough to land a great job at a small startup, and I was pretty awe struck by the talented and motivated people on my team. So after a while of pairing, I picked up a piece of work to try on my own. After doing some copy-pasta from other files and then tweaking I was chuffed and attempted to view the web page that would now be perfect, right?

Much to my dismay I was met with a blank page and an obscure error message. Baffled, bit by bit I undid all my changes, at each step feeling less worthy of the job, until nothing was left except one measly import statement. I could feel myself go red in the face as I still couldn’t understand what was going on. I should be able to do this, but I’m not good enough. Eventually, I turned to my mentor to admit defeat, and my panic dissolved when he said “oh yeah, this one is definitely confusing” then casually pointed out a simple syntax error. I realised that unlike him, I was not yet equipped with the necessary debugging skills, I was not yet familiar enough with the language I was working in to decode the error message. It takes time.

The Library

It has been four years since the import statement that stumped me, but just a few weeks ago, when I volunteered to update a library which was many versions behind, this seemingly trivial task wound up with me ready to quit yet again. Between a broken development environment, failing tests (was it the tests… or the code?), and still this library integration that refused to obey, I was at a loss. I should be able to do this, I should be good enough by now surely? These thoughts drove me to stubbornly dig my heels in and devote hours to diving into the library source code, reading in circles, dipping in and out of StackOverflow, getting more and more frustrated. Much time wasted I was no better off, so I went and made myself a cup of tea and called up a colleague and good friend to lament my problem. Typically, within seconds of this accidental rubber ducking session the solution to my worries became apparent.

The Lessons

And I could probably list countless other occasions. There may be many different things that leave you feeling like quitting, for me it often boils down to not feeling good enough to tackle a problem. But when you come up against a roadblock, you shouldn’t see it as a reflection on your own ability. If like me you find yourself paralysed by feelings of inadequacy, recognise that the foundation of all programming is problem solving – if there were no annoying problems, you wouldn’t have a job – and as you progress through your career you will gain more tools to solve them. Step back and remember, when it comes to tech, there is a reason to be found – sometimes it takes time, distance, or some help to see it.

These are lessons you should try to internalise, or like me you’ll relearn them throughout your career. You can’t change the fact that deeply frustrating problems are coming your way. You can only change your perspective. Put your energy into solving the problem and don’t assume that you’re not good enough. “Good enough” is an arbitrary concept, an ever moving goalpost. Give up on the notion of “good enough” and instead give yourself some time.

Sincerely,

Mia

Mia de Búrca is a Senior Software Engineer working full stack at 99designs, a company connecting creatives around the world. Originally from Ireland, Mia started out as a translator and computational linguist before landing in Melbourne, Australia and setting her eyes on a career in web development. Mia enjoys solving problems with a focus on bringing real value to users and seeks opportunities to create a supportive and empowering workplace. When not hiding from apocalyptic pandemics, Mia is also a circus performer and teacher.

Make it work

This is a guest post from Tim Bourguignon. Enjoy.

Dear new developer,

Let me tell you a story.

Once upon a time, there was a black chalk board in a dark room. The board carried remainders of countless creations. Diagrams that could pass as hieroglyphs for the non-educated eye. Or well crafted UML to the others. From systems to modules, modules to components and component to classes, it all seemed to flow. Generic, inter-operable and reusable, it was beautiful. Those architectural blueprints led the creation of the software. Countless tests secured it, using the best means at hand. Production servers welcomed the bits. But a few week later, the company shut down. There was no market for this software. There was not enough cash left for the company to pivot and explore a different idea. Too much time was lost writing the most beautiful and never used piece of code in the world. Beautiful or well crafted code that doesn’t solve a real problem doesn’t count.

Once upon another time, a software crashed in production. A website was down. A shopping system was not taking orders. A customer was losing a fair amount of money for every hour, every minute and every second that passed. And boy was she furious. A few caffeine-doped hacking hours solved the problem. Thankfulness replaced the customer’s furor. The architecture of the solution lacked flexibility. The re-use potential was at an ever lowest. A bitter smell of copy-paste still held in the air. And the amount of technical debt in the codebase reached new heights. But the fix saved the business. Sometimes, ugly or imperfect code that “do the job” is the best you can hope for.

Here’s how David Heinemeier Hanson and Jason Fried described the launch of Basecamp:

When we launched Basecamp, we didn’t even have the ability to bill customers! Because the product billed in monthly cycles, we knew we had a thirty-day gap to figure it out. So we used the time before launch to solve more urgent problems that actually mattered on day one. Day 30 could wait.

Rework by DHH & Jason Fried

Let me rephrase this: they launched a paid-product with no way to earn money! Does this sound sane to you? It actually is. Worst case scenario, nobody is willing to pay anyway. They don’t have users, they don’t need a payment system. Period. They concentrated their effort on making a great product until the launch date. If the product attracted customers, they would need a payment system. The month that ensued might have been smooth… or very bumpy. Again at the end of that following month, some code had to be running. Good or bad, perfect or crappy looking, it had to do the job. Otherwise they would lose money.

Let’s generalize by putting code aside for a moment. Have you ever written a text to throw it out seconds later realizing how crappy it was? I know I do it countless times every single day. Have you ever had a great idea put you into ecstasy, only to throw it away the moment you put it on paper. Have you ever realized how dumb an idea you had, after hearing you verbalize it? I know I do every single day. Plans are perfect, until they meet reality.

For everything you do, there is a right time. Sometimes it is “yesterday”, sometimes it is “now”. But more often than not, it is “later” or even “never”. The best way to find it out is to strive to make “it” work. Whatever you do, try to make your plans meet reality as fast as possible. Only then can you be sure you are not working on false promises.

Don’t underestimate this first rule. We often forget about it at the first pinch of peer pressure. If you write software as part of a team, you have experienced a variation of the following in the past:

My coworkers will review my code. What will they think of me? I’d better refactor this component, make non-trivial changes to this module, enable future extensions in this class and clean my code up to its core to uphold the design standards…

What I could have done in a few minutes has grown into hours and the peer pressure increases. What has taken a long time to craft must be excellent, or was it the contrary?

Can you live up to this first rule? Our formal education taught us to seek the unattainable best grade and to hunt for any flaws. To the contrary, this rule tells us to seek the “good-enough” and then iterate on it. Use those intermediate versions to foster discussion. Lay a “good-enough” version of your work on the table, be open about its flaws and be sharp in criticizing it yourself. As a group, you can then decide whether to invest in making it suck less, or leave it be. As J.B. Rainsberger said in his talk “7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development”:

If every item in our shop either costs $8 or $13 and we hard-coded those values, we are done!

Of course, not every draft that does the job is production ready. Production is often far away down the road. You will have to work hard to find out what “good-enough” means for every new challenge you face. But by seeking working solutions in your daily life, you will make true progress. Refine working software. Keep both feet on the ground and focus on tiny measured steps. This is the basis for producing a good solution. The solution that is there when the deadline falls. The solution that makes the business work.

— Tim

This post was originally published at Auswanderer Quatsch ².

Tim has been building synapses between human beings since 1983. Passionate developer, Mentoring advocate, mentor and mentee himself, he works as Chief Learning Officer, Head of Agile and technical Agile Coach for the MATHEMA company in Germany. In his free time, he hosts the Software Developer’s Journey podcast and spends as much time as he can with his wife, with [1;3] kids clutched on his back!

When do you feel like you’re “senior”

Dear new developer,

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

“Letters To a New Developer”, the book

Dear new developer,

I hope you enjoyed reading these letters. I’ve certain enjoyed writing them. When I chat with new developers, at meetups, on slack, or via email, they let me know when letters are helpful or unclear. They suggest topics. They give me feedback, which, when you’re writing into the howling abyss of the internet, is very helpful both for calibrating your message and improving your motivation.

I’ve also posted these letters to some online communities. I’ve received plenty of feedback from those folks as well. Some kind, some caustic. That’s not unexpected.

After writing a hundred or so posts, I thought, there’s a book here.

And so I wrote one.

You can buy it from any of the usual suspects:

You can also check out a preview of the chapters on the publisher’s website. I’d love if you’d do so.

Here’s who I wrote it for:

For new developers
You are new to the software development job market. Perhaps you have completed a bootcamp or college degree. You may refer to yourself as an entry level or junior engineer.

While everyone’s background and skills growth happens at different speeds, new developers generally have less than five years of professional experience. Many new developers are worried about their abilities, don’t feel welcome, and have a difficult time finding that first job.

But as an industry, we need more new developers. There are so many problems with which software can help. Companies want experienced engineers, but all the senior developers I know started out as new developers. A senior engineer is just a new engineer seasoned with gaffes, education, and time.

For new developers, this book will help you avoid missteps I’ve made. It also introduces you to disciplines beyond coding critical to success. While programming is crucial for any software product or service, there is much more required to deliver an application.

For anyone considering software development
If you’re not sure if software engineering is right for you, this book offers perspectives on how to succeed.

I’ve intentionally kept the barriers to the layperson low with limited technical jargon. Only a few technologies are discussed, and those sections can be skipped. If you are thinking about becoming a developer, I’d recommend buying this book and a book about programming.

Giving a computer commands that it can execute is an important skill for any software developer. But software engineering is so much more. You must know what to build, how to work with your team, and how to maintain your systems.

For mentors
If you are mentoring a new developer, this book can serve as a discussion guide. Because each chapter has letters approaching a theme from different angles, you and your mentee will find it useful for focused mentoring sessions.

As an experienced developer, you’ll of course bring your own insights and experience to each topic, from your debugging process to the value of an online community for continuous learning.

And, of course, you may have had a different experience than what I share. Such contrasts are a jumping-off point to discuss the diversity available in a software development career.

Introduction, “Letters To a New Developer”

Sincerely,

Dan