How to prepare to be a startup founder

Tree growing around bicycle

This is a guest post from Joyce Park. Enjoy.

To my newer colleagues:

Welcome! I’m so excited to have you in the dev community, and honored to hopefully be able to contribute by sharing a few time-tested hints about entrepreneurship and early-stage startups.

I’m a community-taught web developer who has enjoyed 22 years in high-profile startups – mostly writing PHP and React – but also I’ve been a two-time startup co-founder myself, raised $10mm in venture capital, been written up in a bestselling business book (Give and Take), and am co-founder of the world’s largest meetup for entrepreneurial engineers (@106miles). Since the first week of 2005 – so for 17 whole years now! – we have been helping Bay Area techies get the information they need to found startups without getting horribly taken advantage of. And let’s get real here: the whole startup ecosystem is basically designed to take advantage of your technical talents and also your lack of business acumen. Remember that during the Salesforce IPO it turned out Marc Benioff the business founder owned almost a third of the company while Parker Harris the tech founder owned 2.7% – barely more than their first angel investor.

If you even suspect you might want to someday become a startup founder or founding engineer, I’d like to suggest a couple of practical tips that prepare you for that path.

Learn the basics of venture capital

You don’t need to fear venture capital – remember, they work for you! – but you need to understand the mechanics of how the system works. The easy move here is to read this recent book by the operations partner at top VC firm Andreesen Horowitz: Secrets of Sand Hill Road.

“Operations partner” means Kupor’s the guy who makes the checks show up in your bank account on time once someone else decides to invest. So he doesn’t have that much to say about how startups are SELECTED but he can explain much about what happens AFTER the selection process.

You may or may not have already had the opportunity to learn about the venture capital system from the employee point of view, but in either case this is a good quick overview by former Uber dev Gergely Orosz.

However, remember that the entire available stock pool for employees is generally only between 10 – 15% of mostly non-voting shares! It’s super important to your employees but still only one of the interests you will be mandated to balance when you’re a founder – and a minority interest at that.

Make friends outside your business area

The single biggest mistake I see from early engineering founders – and one I have made myself more than once! – is that they don’t understand how to reason backwards from business models to products. In particular, first-time engineering founders tend to believe other people will sign on to their project because the PRODUCT is so cool and not because the BUSINESS is well thought out.

This article provides a very clear example of understanding the difference between hacking features versus hacking business models. Evite was an older, stagnant, undervalued business that got a new CEO who found whole new revenue streams with only minor tweaks to the product. Even extremely technically sophisticated products – Roblox is a great example here – really took off when they started focusing harder on business model rather than cool demo. I’ve gotten to the point where I don’t even want to know about most 106 Miles members’ products… I just want to know what business they think they’re in.

Business models do evolve over time – for instance self-serve subscriptions were really hard in the earlier years of the Web but now are a foundation of modern computing – so I can’t exactly tell you the precise one you will need to master to succeed in the future. However I can guarantee that you will need to understand the major channels by which revenue can flow to your company, which means you need to understand either bizdev (consumer) or sales (enterprise/cloud) or some combo – and in any case you will need to understand marketing.

I can’t emphasize this point enough: if you aren’t willing to learn about revenue and marketing, and think HARD about it, you aren’t ready to be a founder. And I mean you need to drop the engineering-superiority shitkick and learn from a place of humility because the business model is by far the reason most startups fail. If you’re in B2B, you need to go on some “sales calls” (real or mock) where you talk to potential customers. If you’re in B2C you need to understand how the advertising and lead-gen businesses really work. In either case you’ll need to find out how much it costs to run a successful go-to-market campaign.

Since you’re early in your entrepreneurship journey, the easiest way to learn what you need to know is to look for friends in these functional areas who you can bounce ideas off of. If you eventually decide you need a co-founder, that person will likely be from this pool… so there’s some motivation to hit the marketing meetups and schedule some coffees with salespeople you might know.

Speaking of cofounders… I have way too much to say about this topic, but let me just leave you with one tip: before you start a business with someone, go on a long (minimum 10 day) trip under difficult circumstances (hiking, biking, crappy car) with them. NASA does this to quickly shake down space shuttle crews. Their rationale for the long trip is that anyone can front for a weekend but it’s hard to maintain your social mask after about 5 days without the perks of home and money. You’ll quickly find out how the other person tries to solve problems, how they deal with setbacks, and what fundamentally motivates them.

Practice storytelling

Being a founder means that you’re going to be telling your story over and over and over again: to raise money, to launch your product, to market your product, to recruit, and to exit. The more successful you are, the more of your value to the company will be in this area. And yet most tech founders don’t give much thought to communicating their company’s story, and they don’t take opportunities to practice before the skill becomes a life and death issue for the company.

Even though I’ve given many tech talks – and I recommend it as a great way to exercise your presentation muscles! – I learned the most about it from a cheesy-looking book about Steve Jobs: The Presentation Secrets of Steve Jobs.

The number one lesson I took away from this book was to ask myself harder, “Why should anyone care about your thing?” Honestly that’s what every meeting with a funder is going to be about, and if you can’t answer this question crisply, succinctly, and in a way that excites them… you should re-think your project until you can. Don’t just take it from me, take it from Midas List venture capitalist Garry Tan:

Become a founding engineer

When I was a baby entrepreneur, a venture capitalist once said to me, “Everyone in Silicon Valley came here to work in startups” – but this is less and less true now as bigcos have become more and more dominant in the whole tech industry. I honestly find it impossible to imagine going straight from rocking a company hoodie as you ride the company shuttle bus to your job at a FAANG, to a new reality as a grungy startup founder where you’re going to be cleaning up forgotten leftovers in the kitchen and hiring 12 lawyers at a time. The situation is even more stark for entrepreneurial engineers from areas with few tech startups, who maybe didn’t get a lot of opportunities to learn from close contact with founders.

My entire career has been in pre-IPO startups, and I don’t think you can learn what they’re like without working at a couple of them. But also, I feel that being a company founder is a lot like being a novelist: it’s not a career move, it’s more like having malaria – a fever that recurs periodically. By being one of the first five engineers at a newco, you can try out the lifestyle and see a lot of the shenanigans up close and potentially make a lot of money… on someone else’s dime. Yes there are risks, but an unspoken secret of big companies is that they’ll almost always take you back without much hassle.

A lot of 106 Miles members actually end up deciding they don’t actually want to become founders – that the potential rewards aren’t worth the extra stress, or that their idea maybe isn’t quite strong enough for a standalone company but could be valuable to a complementary startup. There’s nothing wrong with any of this! Great founding engineers are worth their weight in gold to a startup, and they are not easy to find.

This might be a good time to say a few words about the role of the founding engineer, because it’s one of the worst-understood roles in the entire tech business. My friend Dan Moore, under whose auspices I am writing this letter to you, has written a well thought out essay about how founding engineers need to be well-informed, wise, and probably pretty senior. Meanwhile I’ve worked at MANY hot startups and Open Source projects where the founding engineers – the guys (and they were 100% guys) who banged out the initial bits for the MVP – were young, smelly, and profane but able to bust out working code on the quick and dirty.

It is so critical for founders to understand that when you do a newco you’re placing two bets – a business bet, and a technical bet – that trade off against each other. The business bet is that you’ll find product-market fit before your tech debt screws you, and then you’ll have the money to hire an experienced team to rewrite your code when it matters. The technical bet is that quality software will make your business work, and then you won’t have any tech debt to deal with going forward because your software will be perfect – but this never happens. Optimize on winning the business bet ASAP by using quick-and-dirty founding engineers, and you’ll see that money-cash-devs can wipe out all your technical debt pretty fast if properly deployed.

What kind of founder do you want to be?

See this tree growing around a bicycle? The tree is your company, and the founders are the bicycle. Less poetically, founders are the cat piss that you can never get out of the carpet. For better or worse, as a founder your strengths and weaknesses, your quirks and blind spots, your early network… all of this will be reproduced in the company in a way that makes it difficult to reverse. The major method by which this happens is hiring, especially hiring people who become leaders in the company early on.

That means if you care about certain organizational practices, you need to address them WAY EARLY. For example, diversity and inclusion: once you hire the first 10 devs, you are very likely to have the same demographic mix that they represent when you have 100 or 1000 devs. Sorry, we all want this to not be true! But if you care about hiring people who reflect your customer base, you need to think about it from DAY ONE. If your product will mostly appeal to women, you better be thinking about how to hire women right away. If your target market is Latinos, better hire some. If you want to bid on military contracts, maybe hire from the ex-mil pool. If you have a plan and stay ready, you won’t have to get ready when things are hectic.

This may not be your specific issue, but all founders need to think about their deepest ethical values before they start – from the point of view of what would be best for the company, not you specifically. As a personal example: because I’ve had multiple life-threatening health conditions and my heirs are all far older and non-technical, I had it written into my contract that if I die my co-founder will vote my shares but all financial proceeds will go to my estate. This allows for the company to continue to function in a way that it couldn’t if my non-technical heirs suddenly were forced to make important decisions for a tech company. When you become a founder the good of ALL THE STAKEHOLDERS in your company becomes your primary responsibility; and although only you can say how you plan to best serve everyone fairly, I’d suggest that you don’t want to end up the subject of lawsuit or a documentary film accusing you of negligence or egomania.

Join a community of founders

This is a bit self-serving, but I’m gonna put it out there: if you want to become a founder, join up with other founders and learn from them. This is the true secret of Silicon Valley: not that their techies are smarter, harder working, or more connected to venture capital – but that they self-selected to want to learn from each other, and the ecosystem has evolved to support that in a million tiny ways. Organizations like my meetup for entrepreneurial engineers, 106 Miles, will help you get connected to practices and people you can ask for help and talk to – even if you end up rejecting their advice. Come visit us when you’re in Silicon Valley! We may be doing more online events soon as well.

Being a startup founder isn’t for everyone, but if it’s something you have an interest in you shouldn’t wait to learn about it and perfect your founder skillset. Start today! Let me know if I can help – although you should know my specialty is being a “disagreeable giver” – and best of luck!

— Your startup buddy, Joyce

Joyce Park has spent 22 years in startups and Open Source projects as an engineer, an eng manager, and a founder. She recently moved back from Silicon Valley to the Seattle area where she grew up.

Learn caching

Dear new developer,

Caching is a common architectural pattern that helps with performance and scalability. Spending some time learning about this will help you build better systems and understand existing architectures.

What is a Cache?

At the most fundamental level, a cache is a secondary store of a set of values which pulls values from a primary source. There are many reasons why you might want such a store, but a common one is that retrieving the data from the primary datastore is expensive. It could be costly because it is an expensive calculation, because it requires a network call or disk read, or for some other reason.

To avoid the cost of the retrieval, store the value in a cache, and then, when it is needed, retrieve it from there.

Cache Types

There are two main ways to categorize caches.

  • How the data is stored
  • What is stored

Cache data can be stored the same way any data can be stored. In practice, for most applications, you’ll be looking at a few options:

  • Memory
  • Disk
  • Abstracted

Caches that are stored in memory are quick (yay!) but ephemeral (boo!). The cache can go away at any time (whenever the server maintaining the memory is shut down), which means that you can lose access to the cached items at inopportune times. In addition, a memory based cache competes for RAM with other elements of your system. In general, most systems have less memory than disk, which is an alternative storage mechanism.

Retrieving items from disk is slower than memory. Of course, this is true for all disk access, not just that of cached data. The upside of a disk based cache is that you can store far more information.

You can often switch between memory and disk easily and transparently to your application’s code; consult the cache’s documentation to learn more about this option.

The last type of cache is ‘abstracted’. This means you use a cache as a service and don’t really care about the underlying implementation. This could be part of a framework (rails caching, for example), a standalone program like memcached or redis, or a full fledged service like a CDN. Browsers are a cache too. You don’t have to care about the details of this abstraction to take advantage of it. However, you will need to have some understanding of the cache behavior and performance when you operate your software.

Cache Keys

Most caches have a key and a value. The value is the cached value. The key is something that can be constructed by a client to get to the value. There is an implicit communication between the process that puts the value in a cache and the processes that retrieve a value from the cache: they have to agree to how the key gets constructed. Otherwise the cache readers won’t be able to actually read the correct values from the cache.

If you have product data that you are caching, you might have a key of product-<productid>. For a product with the id 15, the data would have a key of product-15. The product prefix namespaces the id in the cache so you can have multiple different types of objects cached (categories, deals, etc). The product id (15) needs to be known by the client to get the data.

Evictions

At some point, your cache will run out of room to store new items. At that point, it will need to get rid of some old items. This process is called ‘eviction’, and there are multiple ways to configure a cache to evict old items:

  • Least recently used (LRU): evict the items that were accessed furthest in the past.
  • Least expensive. If you are caching calculations because they are difficult/expensive to perform, evict the least expensive calculations first.
  • Oldest: evict items that are the oldest. This is also known as first in, first out (FIFO).

Sometimes it can be hard to judge which of these will be the right fit for your system, especially since you may not have a good grasp of usage patterns initially. Generally LRU is a safe choice to begin with.

You should also think about how to trigger evictions. This might occur if the item being cached is materially changed. An example is a new logo for a website. You might want that to be cached in a CDN for years, because it rarely changes and is used everywhere (so you might set the cache period to a long time). But when a new logo is included in a launch, you want to ensure it is used. One way to manually trigger a cache eviction is to use a new name for the logo file.

You might also want to evict a cache item when the underlying source of truth has changed. For instance, if you are displaying the price of an item, when the price changes in the underlying data, you are going to want to display the new cost right away. So when the price changes, you’ll want to force-evict any cache you have. You don’t want someone thinking they can get the product at $X, only to find they are charged $X+1. Not a fun conversation with the customer.

When Should You Use a Cache?

Caches optimize access but introduce complexity. A system is always easier to understand if you pull from a single source of truth.

Introduce a cache when the performance and scalability benefits are required. Otherwise you are simply prematurely optimizing. How do you know if they are required? Evaluate the performance of your code. You can do this by inspection and reasoning about the code. It can be easier to run tests with the cache both disabled and enabled if it is easy to integrate. If you don’t see big changes in performance, there is probably a different slow area of your system.

In addition, think about how expensive a retrieval from the primary datasource is. This will change over time based on your usage and the type of request. You’ll need some metrics to make a good decision as well as to determine if the cache actually helps. Yes, you can introduce a cache and have things be slower, especially if you are on a resource constrained system or you misconfigure it.

Also, consider how much effort it will be to introduce caching. If it is easily supported in your framework or you can add some headers to your HTTP response, caching can be simple to introduce. If it requires you to stand up a whole new system and refactor clients to use it, it can be difficult.

Finally, there are some caches that are built into systems already. Take some time to learn about them; there may be easy wins by tweaking the configuration. Linux has caching as do most databases.

Conclusion

As you might have gleaned from all the examples I mentioned, caches are everywhere. Learning about them and how they can be used is worth your time.

Sincerely,

Dan

But First, Don’t Do the Dishes

This is a guest post from Sonja Parsell. Enjoy.

Dear Developer,

Don’t misinterpret a small distraction, or even a big disaster, as a “sign” that coding isn’t for you.

There were definitely times in my journey when a break in learning was completely justified, but by no means should I have seen it as a reason to quit, or that I was missing the message that I didn’t have what it takes to be a developer.

Thanks to a lot of personal reflection, some low-tech research about my habits, behaviors and values, and not a small amount of tough love, I am happy with my progress now, even though it’s taken years to get here.

Maybe you’re struggling with something similar?

Don’t sweat DO the small stuff.

No outside factor is going to make you more productive, and if you need a certain atmosphere to be at your best, you’re not truly in control of yourself.

Rachel Hollis

I used to feel like the house had to be tidy before my mind was clear to sit down to learn/code. If I couldn’t get those tasks done, how would I ever have time to hold down a software engineering job?

My habit of clearing up the breakfast dishes, tidying up after the whirlwind of getting kids off to school, and letting the “silent do-do list” (totally worth a Google) shout at me was definitely keeping me from maximizing the best time I had to learn to code. I knew if I didn’t squeeze some coding practice in by 10:00 AM, it was likely not going to happen that day. 

Those chores were a waste of my best hours. I learned to walk away from the mess in the kitchen (it was hard at first) and I now spend my most productive hours on my most important goal: becoming a software engineer.

Because really, there will always be dishes and laundry. I really didn’t mean to give them priority. 

Never enough time.

You can’t see the silver lining through victim goggles.

Jen Sincero

I used to think I would never have enough time to learn enough to get hired. Who was going to employ me as a career-changer over 40?

Running is my go-to form of exercise because it’s one of the only things in life I get “enough” of in a short amount of time. At some point, I am tired and I have to stop. That feeling rarely comes when I’m writing code.

As a SAHP (stay at home parent) for the last eight years, my time hardly feels like it’s my own. But everyone has the same 24 hours in a day, right? How could I feel so unproductive?

To solve this, I started with a basic Excel spreadsheet by listing all the things I wanted to do, or were my responsibility (household tasks, volunteering, hobbies, learning objectives, social commitments, family obligations, after school activities, etc.). It seemed endless. No wonder I wasn’t actually doing any of it consistently or well!

After keeping track for a few weeks of what I actually participated in each day, the results were eye-opening. I now had a map of how I spent my time and, most importantly, where I could save it.

The four biggest changes I made to my days were:

  1. Saying “No.” or “Not now, maybe later.” to anything that would interfere with my best coding hours: socializing, volunteering and doctors appointments were strictly scheduled for late afternoons or weekends only.
  2. Waking up at 5:00 AM to have a few quiet hours to myself. This was transformative in how I felt about my progress (by the time I ate breakfast, I had already coded for two hours!) and how the day progressed. 
  3. Giving up a few things. I put a few hobbies on hold, graciously backed out of friendships and groups that didn’t make me happy, and even taught my kids to make their own breakfast and pack their own lunch.
  4. Finding what to learn, when. I lined up coding podcasts for meal prep time. I caught up on all my Slack groups while waiting for the kettle to boil. I quit social media for periods at a time (apart from Twitter – all tech related for me). This helped to keep me focused but not burned out from just sitting at a screen, trying to learn in a silo.

Because really, you have more time than you think you do. You can’t do everything, but you can do anything you set your mind to. Spend your time wisely.

“You want to make websites??”

The first stage of forming an ambition requires imagining yourself in a role that requires skill and that exists outside of the domestic sphere.

Anna Fels, “Necessary Dreams – Ambition in Women’s Changing Lives“

I used to think my family and friends didn’t understand what I was trying to do or even why. So why on earth did I think it was a good idea? I must be crazy.

My friends said things like “You want to do WHAT? You’re training at a bootcamp for a nuclear what?”. (True story.) And there were giggles, looks of confusion, and eventually, they would change the subject, still in the dark about my goal.

My wonderful spouse thought it was an interesting hobby, but wasn’t excited to make space for it if my studying schedule interfered with the division of household tasks.

Through an amazing “Moms in Tech” slack group, I found hundreds of women trying to do what I am. We were all struggling with the same imposter syndrome, were misunderstood by loved ones (at some point in our journeys), and were filled with self-doubt. I decided to enroll in my coding bootcamp on the heels of a meaningful discussion with these women over Slack. I’ll be eternally grateful for their input, and I’m determined to pay back the favor someday to anyone who needs a sounding board.

Because really, your family and friends may never understand what you are trying to do. That’s why the coding community is so critical to your success. Just jump in and find your people. I promise they are looking for someone just like you.

Make progress every day.

It’s not complicated, it’s just unfamiliar.

fellow software engineering bootcamp student to whom I am eternally grateful and wish I knew your name

I used to feel like a failure for not achieving the coding goals I made each day, even if they were SMART goals. If I can’t figure this out, how am I going to move on?

You might want to finish a small feature but when you’re a newbie coder, nothing is linear. First, you need to know what 1a, 1b, and 1c mean, with the right syntax, and know what the errors are telling you, before you can even get to B. That’s NORMAL and it can take a lot of time.

What helped:

  1. Keeping a journal of what I worked on every day. It helps to see your progress in words. And it reminds you of what you learned. Recall is an important part of learning. 
  2. Realizing I had too many things going at once. As a newbie, you feel the pressure – excitement even – to learn all the things at the same time. It’s truly a discipline (and worthy of practicing) to be able to focus on one language, complete one tutorial, or to build one thing at a time.
  3. Repeating a course or an exercise doesn’t mean you’re not learning the concept or syntax. I know I need to see it, read it, watch it and then write it – at least 3x – before it feels familiar.

Because really, you’re still successful if you make consistent progress, not specific goals.

Driving with the brakes on.

Be strict about your goal, but flexible in how you get there.

Rachel Hollis, Girl Stop Apologizing

I used to think that when I had to take weeks or even months off from coding to take care of myself or my family, it was the ultimate sign I should quit. What else could it possibly mean?

I’ve been learning through babies and children under foot, a trans-Atlantic move, a brain hemorrhage, recovering from a brain hemorrhage and vision impairment, and, just two weeks after I spent some serious money by enrolling in a bootcamp, the pandemic hit. All the time I had reserved to finish the program, became dedicated to more housekeeping and homeschooling than ever seemed possible.

But six months into 2020, I was still totally committed to, and absolutely in love with my studies and — guess what – I was finally convinced that this is what I should be doing.

Yes, it took a pandemic.

Because really, changing your life is SO HARD. You just have to work harder. And you can, you just might be lining up at the start more times than you originally thought.

If I belong here, you belong here.

Regret is the thing we should fear the most. Failure is an answer. Rejection is an answer. Regret is an eternal question you will never have the answer to.

Trevor Noah, Trevor Noah: Born a Crime

We are our own worst enemies and often close doors that aren’t ours to close. Only you know exactly why you started this coding journey, and that’s all that matters. Don’t let anything or anyone stop you. 

Especially those dishes.

— Sonja

Sonja Parsell is nearly finished with her software engineering bootcamp. After 15 years on Wall Street working in various finance and operational roles, she’s beyond excited to pursue an engineering career in blockchain. You can read more about her story.

Be kind

Dear new developer,

Kindness is an unsung virtue for software development. I touched on it in this post on empathy, but wanted to emphasize it again.

Practice kindness. When I was young, I thought scoring points and being right were important. They are, but being kind and a good human is even more important.

Be kind to your teammates

They are working with you to try to solve problems. They bring different experiences and perspectives. Value those. Assume positive intent. Yes, there may be the occasional toxic person, but in my career the vast majority of my co-workers wanted to do good work and help our customers.

Be kind to them by listening to them, trying to understand and incorporate their perspectives, and honoring your commitments to them.

Be kind to your users

Making software is an excellent career for many reasons. One of the best parts of my career has been building tools that help others do their jobs or live their lives more easily. To do so requires understanding of their problems, empathy for their constraints, and a vision for how to improve both.

Be kind to them by listening to them, especially when they talk about their problems. Understand that what you do is magic.

(Think of a highly focused discipline that you aren’t familiar with. I’m not a car person, and I still think that the fact that you can turn a car and have the tires go different distances without impacting the overall vehicle speed is pretty magical. This is similar to what users think about developers.)

Use your powers for good.

Be kind to your friends and family

As much fun as coding is, don’t disappear into it entirely. Spend time with friends and family. Forge those bonds.

I promise you in five years you won’t remember the precise problem you were solving today, but the friendship and family bonds you foster will sustain you.

Be kind to them by spending time with them.

Oh, and when you do, don’t talk shop. That gets pretty boring pretty quick.

Be kind to yourself

I read another tweet about a developer being burnt out and quitting the industry recently. It made me sad, because I think I could write software until my 80s. Not full time, but man can it be fun. It can also be horrendous. The environment matters, but so does setting and enforcing boundaries. Make sure you do so.

Be kind to yourself by taking regular vacations, setting and clearly communicating boundaries, and celebrating your wins at least as much, if not more, than your failures.

If you wouldn’t say something to a close friend in the same situation, don’t say it to yourself.

In conclusion, be kind.

Sincerely,

Dan

Uncle Bob’s Ski School

This is a guest post from Dan Walkes. Enjoy.

Dear developer,

I was thinking this week about my Great Uncle, Bob Van Gerpen, who died of pancreatic cancer in 2011. Bob was my Grandma’s youngest brother and similar in age to my Dad. He was a big part of my parent’s life as they experienced the same transition I did, going from South Dakota farm kids to Colorado “city” dwellers in their 20s.

In the long list of Uncle Bob folklore, there’s a particular story which popped into my head this week which I’ve thought about relative to my professional career. It’s the story of Uncle Bob’s Ski School.

As a South Dakota to Colorado transplant, Uncle Bob often had family and friends from the plains who would visit the Rocky Mountains to try skiing, often for the first time. Uncle Bob was not one to turn down a social outing and would always enthusiastically offer to take them up the mountain.

The visit would include helping them with rental equipment, making sure they had the proper gear, recommending the best place to go, finding discount lift tickets, driving them to the mountain, and getting them on the lift. There’d be some discussion about how to “pie” your skis (point the tips together to make a pie shape and slowly slide down the mountain) and some basics about keeping knees bent and suggestions about balance.

The flatlander trainee would ride the ski lift up to the top of the 12,000 foot peak and turn around to see nothing but what looked like a sheer cliff toward the distant specs of people and cars in the parking lot below. As the “student” was contemplating their most recent life’s decisions, Uncle Bob would ski past them, wave, and tell them he’ll meet them at the bottom.

A few hours later, bruised and tired, the newly minted Colorado skier would find Uncle Bob in the lodge at the base of the mountain with an adult beverage in hand.

I don’t know the total list of Uncle Bob ski school graduates and unfortunately the full list is probably lost to history. I do know he would proudly mention both of my parents in the list of successful graduates. He also liked to say his wife, my Great Aunt, was his only failure. After meeting him at the base of the mountain she informed him in no uncertain terms this would be their first and last time skiing together. Borrowing one of his favorite expressions, “a guy could” assume the true number of his ski school failures may have actually been a bit more than one.

As an Engineer, getting outside your own head and describing how to do something you already know how to do can be incredibly difficult. I’m grateful for my somewhat limited experience thus far as an educator to work on this skill. I have a long way to go. One of the things I’ve found to be the most difficult to do in my professional career, both in roles of educator or manager, is to give my students, employees, and coworkers just enough tools to figure out what they need to do on their own. Sometimes I suspect this feels to them a bit like Uncle Bob’s Ski School. Some of them are like my Great Aunt, who are understandably frustrated and ready to bow out after the first trip down the mountain.

Since I’ve been so fortunate to work with a pool of talented, resourceful, and persistent Engineers, however, I find that most rise to the occasion. They are able to overcome my shortcomings in course material or documentation and in many cases learn more themselves in the process. Course material or project documentation is never perfect.

When faced with a deadline the choice is to not share course material until it’s more perfect, or share what you have with the hope it will be useful. I usually error on the side of the latter and I feel like it’s worked out well so far.

If you are a student in a course or an employee working on a new project I encourage you to look at something less than perfectly structured content as an exciting challenge and an opportunity to learn how to learn. I also encourage you to think about what was missing which would have improved your experience and let the originator know or, even better, propose the change to curriculum or documentation which would have helped you and will help others.

When you become an expert, think about how you can optimize your Ski School professional equivalent to strike the right balance of being “perfect enough” to get the trainee started on their journey while minimizing the number who are ready to walk away for good when they make it to the base of the mountain.

— Dan

This post was originally published on LinkedIn.

Dan Walkes is Vice President of Embedded Engineering at Sighthound.

Always be replacing yourself

Dear new developer,

I had a friend who brought me into a club. The specifics of the club don’t matter, but like most clubs, it had a variety of executive roles. Someone had to run the meeting, other people had to take notes, someone needed to keep track of the finances.

As I took on more responsibility in this club, my friend gave me a sage piece of advice: “always be replacing yourself”. You don’t want anything to be your particular special area of knowledge. You should always be trying to train your replacement.

I think this is good advice for a software developer as well. At any new job, you are learning tons of new things. This is doubly true when it is your first or second job.

But, eventually, there will be someone even newer on your team. Whether through churn (if the size of the eng team is relatively stable) or new hires (if you are on a rocket ship), in a year or so you won’t be the new kid on the block.

Obviously this is a discussion to have with your manager, but you should always be looking at ways to replace yourself. This will free you up to work on new tasks and learn new things.

Here are some ways to replace yourself.

Document all the things

Don’t rely on your memory. When you are performing a task for the second or third time, write down what you are doing and why. (If you only do a task once, this is not usually worthwhile.) Keep this under version control and share it widely. That way anyone can see what you are doing and suggest improvements and/or take it over if you are on vacation or doing a different task.

Offer to cross train

When you are working with someone else, you both gain knowledge. Whether this is a command line trick a different view of the world, or specific domain knowledge, working with someone on a task will help you both. This doesn’t need to be full pairing, it could be an impromptu design session or troubleshooting discussion.

Automate for the people

If you are doing a task and have time time, write a script or program to do all or part of this. Don’t let the perfect be the enemy of the done. If you can write a script to do 70% of the work in 10% of the time it would take to automate the entire task, write that script. This pairs well with documentation and is a living form of knowledge transfer.

Obliterate the task

Sometimes a task is always done because it has always been done. With your beginner’s eyes, you can ask “why”. Don’t be crotchety, but try to get to the root of the problem to be solved, rather than focusing on learning the solution. There may be other ways to resolve the issue. There may not. But by understanding the root of the solution, you’ll be better able to see if you can avoid doing it altogether. This isn’t strictly training your replacement, but it will be welcome and does make the organization more efficient.

Don’t be a precious holder of specialized knowledge. Share it widely, train your replacement and you’ll be on to something new.

Sincerely,

Dan

Think about your career risk budget

Dear new developer,

In certain areas of software operations, the concept of an error budget makes an appearance. An error budget is a way of tracking how often errors occur. When the budget is exceeded, you spend time and energy to decrease them.

Having a number like this is a good way to align different areas of the business with the reality that at a certain scale and complexity, issues will arise. When this happens, the question is always, should you spend time fixing the issue or working on new functionality? The error budget helps make the answer clearer. (There’s a lot more to this concept and the link above is worth digging into.)

In the same way, you have a career risk budget. You will work for approximately 40 years, give or take a decade. Each job and career move you make is important, because if you move jobs every three years (on average) you get only 14 different opportunities. These are complex decisions; how can you choose which job at any given time is the right fit? Here are three things I consider:

Goals

This is a very common one. Is this new job moving me toward my goals? Goals can differ for each person, but here are common questions I ask:

  • Is it the tech stack I want? (The older I get, the less this matters to me, but it still matters.)
  • Am I working in an interesting domain?
  • Is this the size of company I want?
  • Will I have opportunities to grow?
  • Will things like work life balance expectations and culture be in line with what I think I want or have enjoyed in the past?

These are all trying to get at an answer to the question: Can I see myself at this company for a while?

It’s always worth writing down your goals and seeing if the company can help you meet them. But it’s also tough to be really clear on goals a few years out sometimes. After all, if you’d asked me in 2016 if I wanted to work in DevRel, I’d have said “maybe??”. Another filter for considering a career move is comp.

Money

I love writing software. I do it for fun sometimes. But the fundamental employer employee relationship is through compensation. I give an employer my time, knowledge, experience and energy. They give me money.

So there’s nothing wrong with picking a job based on money. In fact, from my experience and the experience of others I’ve talked to and read about, switching jobs appears to be the best way to get solid salary raises, especially in the current market. Some of the numbers I’ve seen are eye popping, including double digit increases. You won’t get that at the same company, typically. (However, I did get some double digit raises early in my career, from 42k->55k at one company, so it isn’t out of the question.)

Make sure chasing a higher salary aligns with your career goals too. Funnily enough, jobs in software which are unpleasant, career limiting or otherwise less desirable often pay more (the free market at work). So when you see that junior engineer position using MUMPS which pays 10k more than other positions you’ve seen, find out why.

Money is important, but not the only thing to chase. There are risks to any job and it’s worth thinking about them.

Risk budget

Another approach to fold in is your risk budget. There are all kinds of risks, but you want to look at financial, emotional and career risks.

  • Is the company going to be able to pay you? Do they have a viable business model? Do you feel like buying a lottery ticket (equity) with your time?
  • How are you going to feel working at this company? A valued part of the team, or an expense to be managed (or, worse, minimized)?
  • Is this position, in terms of responsibility, technology, and growth opportunities, going to help or hinder your career?

You can’t, of course, quantify all of these precisely, but you can assign relative numbers to them. This can be helpful when comparing opportunities, either side by side or over time.

Risk budgets change as you age, as well. For example, your financial risk budget may decrease as you have more obligations. On the other hand, it may increase if you build up savings or have a cushion.

As I get older, the team I am a part of has become more important and the precise technology less important. But that’s me. You need to take some time and think about what matters to you.

Sometimes you have to take a job to have a job. I get that and have been in that position. But if you have the luxury to have some patience, consider the above three factors and don’t forget your risk budget.

Sincerely,

Dan

Why Developers Should Engage in Continuous Learning

This is a guest post from Jerrin Samuel. Enjoy.

Dear new developer,

Software development is a field that evolves quickly and constantly. These changes keep things exciting and interesting, but can also make you feel like you are falling behind all the time.

Engaging in continuous learning is one of the solutions you can look into to stay updated in your profession and avoid feeling left out.

Continuous learning refers to the process of learning new knowledge and skills on an ongoing basis.

This type of learning can come in various forms, including enrolling in formal programs, such as taking up technical training courses, attending seminars, and engaging in self-study. It can also be sponsored by the employer or take place within the company, or it can be personal.

Benefits of Actively Participating in Continuous Learning

Continuous learning provides professionals in the field of software development several benefits, which include:

Remaining relevant

Since software development is a constantly evolving field, you need to stay up-to-date with all the changes that come up.

Taking up development or IT courses allows you to keep up with the latest trends. Moreover, you can broaden your knowledge and skills, enabling you to adjust and function effectively in the dynamic world field of technology.

If you want to remain valuable in your organization, you have to learn new things constantly.

Boosting your profile

Learning constantly means you are continuously growing and improving.

This also means adding more skills to your CV and profiles on various recruitment and job posting sites. These additional highlights can make your profile stand out and catch the eye of more recruiters and employers.

The certificates you gain and the recommendations by your managers and colleagues will also make your profile more attractive.

Improving your employability

Professionals who are constantly learning and upgrading their skills create a higher market value for themselves.

This is because employees that always stay relevant are highly sought after in the job market. As a result, employers go another mile to hire or retain them.

Preparing for the unexpected

Continuous learning helps you acquire skills that can propel you towards achieving success not only in your current workplace, but also in other companies.

Since the economy can be erratic at times, you need to be prepared for the possibility that you may lose your job. Having broader, up-to-date skills can increase your chances of getting employed again as soon as possible.

Your broader range of skills can also give you the confidence you need to take on new job opportunities so that you can get employed faster.

Increasing your self-esteem

Learning new things gives you a feeling of accomplishment. This, in turn, enhances your confidence and belief in your capabilities.

As a result, you will also feel more ready and confident to take on challenges and new job roles and responsibilities.

This boost in confidence will also improve their emotional and mental health. What’s more, it will increase their productivity.

Enhancing your creativity and problem-solving capabilities

Joining software development courses, seminars, conferences, and other reskilling and upskilling programs allows you to learn from the trainer or facilitator and your fellow learners.

Because of this, you will be able to come across new perspectives, techniques, and strategies that can help you think outside the box.

Whether you come across a problem that requires innovative solutions or need to create something new that has never been done before, you can also use the knowledge you learned from others to meet these challenges.

Broadening your mind

Continuous learning allows you to expand your mind and perceptions, thereby helping you change your attitude.

The more you learn, the better you will be at seeing things from different perspectives.

Your open-mindedness can help you relate and communicate with people more effectively. Whether you want to broaden your professional network or social circle, your new outlook and attitude can set you on the right track.

Getting the Most Out of Continuous Learning

When engaging in continuous learning, consider trying out different strategies. Aside from taking formal in-classroom and online courses, seminars, and workshops, be open to joining employee and managerial training programs.

Participating in social learning opportunities, such as team meetings or discussions and collaborations, are also effective strategies for upskilling and reskilling.

Coaching, mentoring, and on-the-job training programs also count as social learning opportunities, and thus, will contribute to your personal and career growth.

Lastly, there is also nothing wrong with branching out if you are interested in other fields. If you have the opportunity, learn skills not related to software development but can still contribute to your personal and career growth.

A project management, business writing, or employee motivation training course are excellent options to add to your portfolio.

Learning should be a continuous process. Always include it in your goals to experience growth personally and in your career.

Sincerely,

Jerrin

Jerrin Samuel is the Executive Director at Regional Educational Institute (REI) in Abu Dhabi. Since 1995, REI has been at the forefront of education by delivering quality corporate training courses in the UAE, helping many businesses and organizations achieve greater productivity and higher customer satisfaction levels.

Take jobs that help you grow

This is a guest post from Adam Steel. Enjoy.

Dear New Developer,

Getting your first developer job can feel like a big accomplishment. And it is! It can feel so big and you can feel so relieved to have any job at all that you might start to develop your worldview around that one job. “This is how things are in the real world” you might tell yourself. “I’m lucky to be here,” you murmur. “Leaving too soon looks bad on your resume,” says an older friend.

This sort of thinking can be entrapping. I’m writing to show you a better way.

The spectrum of jobs and companies in tech is broad. To understand how the world is and what your options are you have to take a couple samples and grow, grow, grow! To that end, there are three “traps” I see developers get stuck in early in their career.

The first trap: Spending too long at your first job

In your first 3-4 years, it’s critical that you fuel your motivation and inspiration into learning and growing. It’s also a critical time for a steep increase in your salary. Too many companies fail to recognize that a junior developer’s abilities are growing far faster than their compensation and responsibilities. Or it’s recognized but the company cannot afford to promote or give a raise. It’s up to you to take the reins and move to a new job to find the new challenges and new salary that match where you are in your career. This is especially true for self taught and boot camp taught developers.

How long is too long? How long is enough?

“Enough” time as a junior can be surprisingly short, depending on how you learn. At 6 months it is reasonable to consider switching jobs if you are learning quickly. Not for all positions you’ll hold, but specifically for this first one. Juniors are paid less because they need to come up to speed on all the terminology, tooling and processes.

Once you don’t need hand holding to tackle moderately complex features, you will be far more attractive to other companies. Occasionally a company may recognize and reward your growth, but that is rare.

Stay longer only if you’re feeling significantly rewarded and challenged. Which brings me to…

The second trap: Not investing in learning

Building business software in teams requires a set of skills that are hard to acquire in the absence of customers and a team working to support them. This learning curve can only be tackled when you have these components. And the best way to move along the learning curve is to take a job that helps you learn faster!

What does a “learning” job look like?

“Learning” jobs tend to have similar characteristics. There are resources to learn from and the autonomy to work however suits you best. There is time built into the team’s cadence to allow for research, either organic time throughout your week or time specifically set aside.

Most importantly, there are lots of smart people who give you feedback and engage in discussions about the best way to do things. These people will focus on things like best practices, optimization and customer value. Often they argue! While the arguments might excite you or wear you down, they should feel overall productive and, at the end of the day, move the team toward its goals.

Think of a learning job like an additional career investment, beyond whatever you’ve already paid to learn before your first job. What you need is exposure to good ideas in the context of solving a business problem with an experienced team, and a good learning job gives you that. You may take a lower salary in the short term, but by expanding your knowledge your career will be more fulfilling long term.

What should I avoid?

The list of positions where learning is difficult is much longer than the list of “learning jobs”, but here are some examples:

  • Isolation: Working alone is the hardest career decision to come back from, but it’s especially destructive in your first job. If you aren’t challenged by the ideas of multiple people, your world becomes small. You also won’t have a chance to build your network.
  • Micromanagement: Good companies work to give their developers autonomy and space to do the right thing. If someone is managing the details of your daily life, you aren’t learning how to flex that autonomy muscle. For example, once I had a job where a senior manager stood over my shoulder and dictated what he wanted to see as I wrote code.
  • Lack of visibility: Do you get a chance to learn how the pieces fit together? Do you get a chance to fit them together? A narrow field of view restricts your ability to build a larger context. For example, are you only ever asked to fix specific bugs, or are you encouraged to think about the larger architecture while building new features?
  • Unsafe environment: If we don’t feel safe, we cannot learn well. Depending on the threat, there could also be much bigger concerns. Examples include, but are not limited to, yelling or harassment of any kind. Leave as quickly as you safely can.

The third trap: “Being glue”

“Being glue” is when your role is focused on filling gaps like coordinating between teams and keeping everyone organized, as opposed to actually writing software. Especially in smaller, more dysfunctional teams it can be a tempting role to fill. The team needs it, after all! It’s an important role for managers and higher level engineers to fill, but if you step into it too early it will stunt your learning curve and can leave you forever feeling like you are “behind” the rest of the team. It’s first (and best) described in this noidea blog post.

Once you are technically competent, and everyone knows it, consider taking on this work.

Finding a job that maximizes your growth

There’s no silver bullet for this problem. My best advice is to try to develop the ability to “sniff out” the kinds of companies you’re looking for. Did someone impressive speak at a meetup or write an inspiring blog post? Track down where they work. Job descriptions that are well written and articulate good values are promising. And if you end up in a job that you misjudged and find yourself stagnating, don’t feel guilty about quickly moving on.

Consultancies with great practices, like TestDouble, can be great accelerators for your learning. Changing projects more frequently results in a broader experience, but at the predictable cost of less experience with how your decisions in a codebase will age.

What does a “good” job description look like?

Writing a good job description is hard, but the best companies will put in the effort to do it right. Some attributes of good job descriptions include:

  • Reasonably correct English and readable formatting
  • A description of philosophies and values that align with yours
  • Reasonable requirements (e.g. no CS degree required for a junior level frontend position)
  • Specifically calls out personal traits like kindness or empathy as desirable

What can I ask in interviews to vet the position?

Remember that interviews are your chance to interview them as well. Examples of questions you could ask include:

  • What best practices do you think have made your team successful?
  • What kind of developers thrive at your company?
  • How do you support developers when they come onto a team?

How frequently can I change jobs?

This is a hot topic, but varies by which part of the industry you’re in. Early on, hopping jobs more quickly is fine. 3 jobs in your first 3 years? Not uncommon. Working in startups especially can lead to shorter tenure as companies fail or are acquired.

However, there are skills and wisdom you will only be able to build by staying longer. For example, no amount of training or reading will result in the wisdom you gain by wrestling with a technology decision you made over a year ago as you watch it cause painful issues.

The resume to avoid building is the one with only <2 year tenures over a 10 or 20 year career.

Happy growing!

Adam

Adam Steel is the VP of Engineering at TrueCoach. He lives outside Boulder, CO.

Act like an owner

Dear new developer,

I’d like you to close your eyes and put yourself in a couple of situations.

First, think about a car you have owned. If you haven’t, think of something else that you own and take care of.

I have owned an automobile. I changed the oil regularly in my car; okay, that’s a fib, I paid someone to change it, though.

I took care of any warning lights that came on, even though almost every visit to the mechanic resulted in bills. I definitely avoided driving over potholes. I listened for out of the ordinary sounds and, if they persisted, visited that same mechanic.

My cars aren’t maintained in mint condition. My current car has some dents and scrapes. I drove a car with a crack in the windshield for about 7 years. But, fundamentally, I take care of cars I own. Cosmetic dings are ignored, but root problems are addressed.

Second scenario. Have you ever rented a car? If you’ve owned a car, how would you contrast the level of care for a rental? (If not a car, how about a home?)

I have rented cars. I’m no dummy, I don’t want to lose my deposit or have the rental car company charge me when I return the car. I take some care. But I certainly don’t care for a rental as carefully as I do a car I own.

Hitting the occasional pothole doesn’t bother me. I certainly wouldn’t pay to have the oil changed.

With a rental, my incentives are different; all I really have to do is get it back in much the same shape at the end of the rental period.

Enough with the car analogies. Let’s talk about work.

When you are an employee, you are trading your time for money. When you are an owner, you are building a long term business. (How long? Some times for years, sometimes for centuries.)

Having been both an employee and a owner, I can tell you that being an employee is much like renting a car. A few issues here and there, especially if they won’t cause problems for years, won’t bother you too much.

Being an owner, however, is more like owning a car. You want to, at a minimum, take care of the fundamentals to keep the engine running. Depending on how mature the company is, you also may spend a lot of time tuning and improving the business, just like a car owner might invest in better shocks or tires, or change the oil themselves.

So, what’s this letter really about? Take an ownership mindset. It will set you apart from all the employees that are just treating the company like a rental car.

Some things you can do:

  • Ask “how will this change affect the codebase in 2 years? In 5 years?” You don’t have to do this all aloud all the time, but even asking yourself this question before diving in can help you make the change in a way consonant with the overall codebase.
  • Document code, processes and decisions. Two very valuable areas to document are confusing things and project setup.
  • When you encounter a bug, if you don’t have time to fix it right away, file an issue for future reference.
  • Write tests.
  • Talk to team members and try to understand why things are they way they are.
  • Interact and learn about other parts of the business.

However, just because you have an owner mindset doesn’t mean you should do everything an owner does. If you are an employee, set boundaries. An owner of a business can, and sometimes must, work beyond normal hours. They will reap the rewards of this extra work.

When I was building the MVP for a startup I co-founded, I worked every single day for a month. (Others have done far more, of course.)

But if you aren’t really an owner, set boundaries, particularly around your time. Why? Because at the end of the day, employment is still a trade of time for money. The residual value and control of the company rest with the legal owners.

In short, during the work day act as if you are an owner of the company. This long term view will differentiate you from other employees who are just trying to return the rental car and not lose their deposit. Then, when quitting time comes around, focus on other parts of your life, because it isn’t your business.

Sincerely,

Dan