This space intentionally left blank.
One of the things I love about the modern-day world of internet-as-a-everything is that I have different ways to support people who are doing creative things.
I ordered a nice Mooncast t-shirt to support a friend’s startup. You, too, can support small indie game development and possibly slide one or two of Jeff Bezos’s nickels my way.
I also recently bought a Star’s Reach shirt, but that one is password-protected for alpha testers only. Hopefully, they open a store for everyone soon.
Cake is a disgusting mashup of flour, sugar, and at least one reasonably edible ingredient. Pie, on the other hand, provides a framework for deploying any number of super delicious ingredients inside an edible sleeve.
I love me some pie. When I was a kid, I used to sneak off and pick wild raspberries until I had a gallon pail full, and then my mom would make me the most amazing raspberry pie. You can buy “Raspberry Pi” on the internet now, but it does not taste the same.
I am not going to follow up on this with a recipe. My mom took that recipe with her to the grave. This is not that kind of blog post anyway. I cannot bake to save my life.
It can be challenging to figure out how to split equity when starting or joining a company. You want to understand the exits and your upside during a liquidity event. Another important consideration is what you bring to the table related to the company’s age. I proposed joining several small companies early on as a first engineer for between five percent and forty percent of the company. Some of this had to do with the idea’s strength, the founders’ strength, and how much money was already raised for the business.
You want meaningful equity, and you want to know that the people you work with, known as your “first team,” have your back when it comes to taking you to a liquidity event.
The journey to a liquidity event is complicated. Most people want something magical to happen in two to four years, and you are more likely to wait seven to ten years. I was in the “two to four years” misinformed camp early in my career. I know better now.
The interesting thing about equity is that it tends to change over the life of a business. Most often, your slice of equity will get smaller. When this happens, you have to ask yourself if the business’s overall value will go up based on the change in equity. If the business value increases, then the dilution is worth it.
Sometimes, you will also find people who do not want their equity stake to evolve. This might relate to the amount of equity needed to control the company or to their perception of their own value and the relative worth of the business.
This is often boiled down to the question:
“Which is better: Bigger piece or bigger pie?”
If you have a scalable business or investors who believe you have a scalable business, you will probably fall into the “Bigger pie” camp. If you have taken venture capital, this is a pretty natural evolution. You raise some seed money, then a series A, then a series of additional rounds B through E, to either make a run to the IPO border or to be acquired somewhere in the middle of that run for a good return for the investors.
You should keep as much equity as possible if you have a small business. You will want to scrutinize the people you bring into your cap table carefully and be sure not to fall into the minority of your own company. If you want to read a tragic version of this story, Gary Gygax, one of the creators of Dungeons & Dragons, lost control of TSR, Inc. this way. You can read about that in Slaying the Dragon.
So which is better? Bigger piece or bigger pie?
It is hard to give a definitive answer.
There are some times when you will want to keep a bigger slice. It is worth examining these opportunities carefully to ensure you are not falling into a scarcity mindset trap or that keeping the equity levels where they legitimately make sense.
There are other times when you will want to create a bigger pie. When you raise money, your investors will want to own more of your company as a condition of increasing investment rounds. You should also grant some equity to advisors or key staff who want to accompany you on your journey. You should be careful about the equity levels you grant and what time frame you grant them. Having advisors with high equity levels or former founders who also have high equity levels, you might risk having a confusing cap table that will inhibit future investment.
In many cases, the right answer is not clear. You might not know whether or not you made the right decision about “bigger piece or bigger pie” until it is too late.
Are you faced with this decision today?
As someone who has been through many equity-related decisions, I am happy to have a courtesy conversation with you and give you my perspective.
We are a little late this week for a plethora of reasons. A plethora. What a great word. Stand up and say it out loud: “Plethora.” Hopefully, you are somewhere where that is quite strange, and you should nod to everyone around you and tell them, “Think about it.”
One of my writing goals is to discuss the mistakes I have made in my career, even if I do not want to admit to myself that they were mistakes. 2001 to 2006 contained a lot of deep, deep learning, which is a fancy way to say, “mistakes so big, you can see them from space.” For example, many dark things occurred at Digital Chocolate, and my actions required many people to proclaim “shenanigans!” The directionality of my actions, if not the actual actions themselves, was still reasonably correct. This is a series of confession booth conversations that still need to happen. For the record, I have apologized to the CEO for the worst parts of my conduct, even if there were people between him and me that I still think deserve prison time.
I will not serve up the rest of the red meat slash hot goss from 2004 here.
Today, I want to talk about a more recent mistake and probably a less fatal one.
In recent memory, I was talking to my boss and CEO about a series of random tasks that showed up from a customer. The task seemed like a foul-smelling concoction of menial work and time-consuming meetings. The CEO said they would own this task and see it to completion.
“This is what I signed up for.” Was the magical declaration that followed a description of the banality of the task.
This is a very important statement. In leadership, you have to understand what you have signed up for. In most leadership positions, an important thing to realize is that when you have some work that is not suitable for anyone else, it is your responsibility to ensure that it gets done.
At a certain level, “this is what I signed up for” becomes “this is important, and not what anyone else signed up for, and therefore it is what I signed up for.”
For most of your career, you must ask yourself, “Is this what I signed up for?” I think that modern-day work-life balance and the need to be your authentic self at work can sometimes lead people to a hard “No.” For an entire generation of managers, this can be confusing. Most Generation X leaders, for example, grew up in a work environment best described as a “toxic meritocracy.” The importance of working hard to get things done was important regardless of the craziness of the task. Everything your boss asks is what you signed up for.
This is less true today. People value their personal time and draw hard limits on forty hours a week. People look at the companies they do business with, their values, and whether or not they align with the company. “Is this what I signed up for?” is a harder question for most people today than twenty years ago and contains much more nuance.
Everyone has a different mindset here, reflected in their answers to “Is this what I signed up for?”
My failure here is incorrectly answering this question. I was preparing for an interesting, internally focused executive task and needed to pinch-hit on another more urgent customer-facing task. I asked myself, “Is this what I signed up for?” The surface answer is that I had signed up for the internally focused executive task because that aligns with my current responsibilities. This other customer-facing task is not personally more interesting or important to me. I accepted the task and worked through it, although not without its cost. On reflection, I tended to complain about it to my peers.
When you reach the executive level, you must treat the question, “Is this what I signed up for?” differently. Very differently. The business has a different meaning to you than it did as a worker-bee or even middle manager. You have duties and obligations as leadership to fulfill in pursuit of the company mission, and it is best to follow through those with some level of grace and decorum.
In the future, when you face executive tasks that do not feel like they are in your wheelhouse, you should consider whether or not you have the luxury of saying, “I did not sign up for this.”
At a certain point in your career, “Is this what I signed up for?” becomes a non-question. Everything that needs to get done is what you signed up for.
I am adding this to my list of conversations with people on the verge of executive promotion. They need to understand that what they think they signed up for is sometimes different than what they really signed up for.
See you all next week!
Much like Elrond, I will give you a rough idea of how old I am by saying, “I was there when…”
I was there when Fonzie jumped the shark.
As a small child, I remember our ritual gathering around the television set when Happy Days was on TV. I have similarly vague memories of slightly burned stovetop popcorn, hockey games, and episodes of Three’s Company.
Today, we are going to talk about shark-jumping in software development. Oddly enough, this is not a conversation about Jira.
This is a conversation about Zoom.
I know many of you are going back to wearing fancy dress shirts and khaki pants and making “herp derp return to office herp derp” noises these days or honking like a loud, obnoxious goose going, “Hybrid! Hybrid! Hybrid!” Some of us look at you in the rearview mirror with a mixture of pity and… okay, well, lots of pity. I enjoy my “remote work is best work” t-shirt that matches my coffee mug. I am also not wearing any pants.
There is a certain inevitability to remote work that has gradually improved through better and better technologies to enable communication and interaction.
Currently, Zoom Meetings (apparently Zoom Workplace, as the application declares itself) is one of the shining jewels of “Hey, let’s have a remote meeting together!” Perhaps its meteoric rise is tied to the sudden pandemic, or it did so many things better than Google Meet or Microsoft Teams. For whatever reason, Zoom has risen to the top.
It no longer deserves to be there. Almost weekly, something changes inside Zoom to make it a less great product than the day before.
So what is happening here?
I frequently make a joke about how Apple is trying to be Samsung almost as hard as Samsung is trying to be Apple. In much the same way, Zoom is not doubling down on what makes it great as a market-leading product; they are trying to become something it is not and pushing toward second place.
Whatever “Zoom Workplace” thinks it is, it is not just the best place to hold virtual meetings. It has bolted a pile of features onto itself Frankenstein-style.
A score of UX changes to the product over time have confused me, from the hexagon-shaped exit button that replaces the “leave meeting” door if you are the meeting owner to the sudden increase of random popup dialogs at the top of the window. Most recently, each meeting I have entered includes a button labeled “Not hearing anything? Turn Up Volume.” Is this the most common tech support problem that Zoom users have?
If you regularly record meetings, the button location on the “you are sharing screen ribbon” changes repeatedly, from one of the most important buttons to something buried beneath the fold.
When sharing screens, you must mouse over an area at the top of your screen to pull down the ribbon that was previously at the bottom of the Zoom window, only to find that it does not mirror the ribbon in size and button layout.
Everything that has happened to Zoom in the past eighteen months has not made it better software for holding remote meetings for me.
Even more shocking is that it lags behind Google Meet in interesting features I have sometimes needed for a meeting!
I find it horrifying and fascinating at the same time when marketplace leaders do this to themselves. There is some kind of twisted incentive somewhere that drives product managers and company leadership to make changes to their software just for the sake of making changes.
You could argue that they have lost their way, as evidenced by their desire to have people back in the office.
Whatever they are doing is not suitable for their core business. I have no interest in wiring them up to my calendar, which leads Zoom to tell me, “No meetings scheduled. Enjoy your day!” First, I have plenty of meetings scheduled, and second, why is that a necessity for me to enjoy my day?
I just don’t understand what they are doing. This implies that they don’t know what they are doing either.
I hold at least my monthly staff meeting in Microsoft Teams as a polite reminder to wait for the day Zoom sinks so low that this will be an obviously better experience.
That day is still pretty far away, but every time I see new pixels inside Zoom, it feels like it is getting closer.
I am not sure what else to say.
If you manage a successful product like Zoom, you should ensure your changes to the product make it a better product.
See you next week!
I write this blog for many reasons. One of my goals is to help people learn important, hard-fought lessons without experiencing some of my pain and suffering.
According to Nvidia’s CEO, there are also times when it is important to learn those things yourself.
So when my oldest son Carson started fiddle-faddling around with no-code platforms and told me that no-code application development is the future of software development, I nodded, I smiled, and I did nothing.
I will not bother linking to the random no-code platform that captured his enthusiasm. Instead, I will smugly link you to his public Instagram page. It is even there in the name.
Over the next six months, I listened intently to him describing his no-code journey with some amount of nervousness and fear. It is one thing to hear his opinion on the future of software development and yet another to take prescriptive action and correct him.
Fast-forward two years, and all of that “doing nothing” has paid off. He has started building his APIs and platforms in Python and is running a growing business.
Somewhere along the way of coaching and teaching people, I have learned that it is important for a teacher to know when not to teach.
This is a serious problem for today’s staff engineers and architects. Many talented software developers have gone through that zero-to-one transition for creating software platforms. Many more have learned how to scale up through growth measured in thousands of percent from their current user base.
Their problem is that they need all their lead and senior software engineers to go through the same exercises to learn the necessary patterns to operate at a higher level.
For this to happen, you must let your teams propose systems that might not be ideal or forward-thinking. You can softly give them feedback that there are missing pieces and give them some gentle and subtle clues about bridging the gaps to the solution they will eventually need.
Far too many engineering leaders will do all that work themselves and lose a valuable teaching opportunity. Maybe there is some scarcity mindset or fear involved, or it is simply a lack of forethought on their part, and not in a bad way because they have never needed or wanted to grow one or more engineers to a peer level.
I guess this is just a restatement of the old saying, “You can lead a horse to water, but you cannot make them drink.”
Please make sure your mentees (and yes, your children, too, although technically, this is not a parenting blog) have enough opportunities to learn valuable lessons on their own sometimes.
When the opportunity arises, and they are either successful or not, let them know that this was an intentional opportunity and that they are wiser for it.
The explicit statement afterward is important for creating psychological safety. If your teams know they have some opportunities to grow, including some risk of failure, they will be far more impactful than a team that slips task management tickets while keeping on a narrow track.
Have you ever gone to the internet to search for something you needed to buy? Once, an overwhelming sense of professional obligation to own all of my work software inspired me to obtain a Visio license. Rather than going to Microsoft, which may have been the most obvious thing to do, I went to Google and typed “Visio.” This was in an era of significantly more aggressive adversarial advertising. There is some kind of sick trust between Steve Ballmer and the average Microsoft customer that inspired them not to spend money on buying Google ads. While I am a gigantic fan of Microsoft developer products, I was not so in love with the Visio brand that I was willing to completely ignore the product offers from Microsoft Office competitors. SmartDraw was at the top of the sponsored links at the time, and it looked like they were ready to party.
This is how I became one of their customers. I was seduced by the novelty that Microsoft was so flagrantly uninterested in my business that they did not wish to pay to stay on top of the Google advertising spender leaderboards. I felt like I was some super-smart bargain hunter for the simple act of a mouse click.
I have about six or seven very good years of architecture diagrams from my steady relationship with SmartDraw. I think the success of their clever marketing began to cause problems. They began to iterate on SmartDraw like professional arborists “iterate” on the plants that are “under their dutiful care.”
There was a particular release where they stopped maintaining feature parity with Visio.
I don’t know what to say about what happened next. A breakup? A funeral?
SmartDraw and I were no longer seeing each other, that is for certain. After so many wonderful years, why they decided to make this change is unclear. I imagine I was not the only person who stopped using their product that day.
This is probably the first time I realized how important advertising or marketing your product is. I was a product-first “if you build it, they will come” entrepreneur. Maybe parts of me still are. Not the Derfdice part, though. I built it, and nobody came. There was a mild collision there between my aspirational view of the hardcore tabletop game dungeon master and the arrival of LLM technology. It was quite humbling to get zero million customers. Fortunately, I broke even on the product in other places and other ways.
This is a short one today. If you ever want to throw some money at a company for a product, seeing who else wants your money more is worth it. I am firmly back together with Visio again if anyone is keeping score. I have found additional replacement products over the years. Oddly, the next best example is also a Microsoft product. I was an Intellimouse lover for years, and now I find myself besties with the Razer Deathadder.
I would love to hear some stories of “surch…” Where you go to the internet to find a product and purchase something better or cheaper.
See you all next week!
Before you think that my blog subject is some kind of boop boop lazors noise from a space movie, I want to point out that it is my own cleverness in writing “three-in-a-row.” Yes, I am fine. No, I am not sorry. I am not going to blink twice, I am not in danger.
Today, I want to talk about three-in-a-row. I have selfish reasons to avoid calling it by its proper name. If you have ever gone past the “let’s send John a resume” phase of a professional relationship with me, you would be on the receiving end of an obnoxious IYKYK. You can Google that if it confuses you.
Why are we talking about three-in-a-row, aka tic to the tac to the toe?
Because when other people ask me, “Hey John, how do you learn a new programming language?” This is the first program I write.
The first thing I do is build a three-in-a-row game.
I do not have an unusual affection for three-in-a-row. Using the popular minimax algorithm correctly would make an unbeatable puzzle that fails to define a game. I love implementing three-in-a-row as the first thing I build in a language because it has a few abstractions that are good ways to flex your ability to use a new programming language.
Multi-dimensional arrays: You should store the board in an array of [x] and [y] values.
Some business logic: Deciding where an AI player should make a move is a fun little exercise.
Inputs and outputs: Hello world is nice but you are just printing things. Making a full command line (or graphical) game requires more mastery. Are you processing clicks? Are you converting input to numbers? Is your input good? Are the moves valid?
The classes: You can put the board and the player into objects, even with a little inheritance from GenericPlayer to AIPlayer and PersonPlayer.
When I do this, I generally do not use minimax. I like to make a reasonably simple set of functions that iterate over the board, reusing a common function to see if a row is complete or is about to be complete.
I also added a random chance for the AI to make a useless move to ensure the game does not always end in a hideous tie.
So here is a little pseudocode logic for you on the AI’s turn.
if( MakeWinningMove() == FALSE ) {
if( MakeDefensiveMove() == FALSE ) {
MakeRandomMove( );
}
}
This seems pretty straightforward. Try to win the game. If you cannot win the game, try not to lose the game. If neither of those are serious issues, then make some random move and be done with it.
In the function MakeWinningMove(), for example:
We will make a list or set of all the empty pieces.
We will loop over this list and temporarily add an AIPiece.
Does this give us three AIPieces in a row?
Return TRUE!
Otherwise, remove the AIPiece from this location and restart the loop with the next value.
I reuse an iterator function that checks horizontal, diagonal, vertical, and reverse diagonal lines in a 1 to N loop. I think it is important to avoid magic numbers. Suppose someone sends me an implementation of a three-in-a-row game. I look for a variable or constant declaration of BoardSize set to 3 and almost immediately increment it to 4 just to see what happens. Sometimes, it works, and sometimes, it doesn’t.
The logic for MakeDefensiveMove (and MakeRandomMove) is largely the same. Avoiding DRY (Don’t Repeat Yourself) Violations is a good practice.
By the way, this is not the best implementation for three-in-a-row. It is fast and easy to test and does not crush players’ souls by being totally unwinnable.
Quite a bit of this post is about hints for what I look for when conducting software code screens. I was trying not to say that in easily searchable terms for future engineering candidates. I have made this obscure enough that the bonus points for anyone improving their code submissions after finding this article will be worth it.
So now you know how I learn new programming languages. I try to do this frequently enough to stay a lifelong learner and I think this is better “gud brain” exercise for you than tugging at the chunks of wood and metal that you can buy from Amazon at this affiliated link right here. See you next week!
I spent some time looking for engineering coaches for others a few years ago. While conducting early interviews to understand what they do and how they measure their success, I got a lot of puzzled looks from potential coaches. Most of them measure their success by the size of the fire they have put out via their coaching, and almost none of them were being asked to coach people where there were no issues.
I was equally puzzled by this. Having coached many people on my team and a few outside of my team, surely the executive teams at most companies understand that you want to invest universally in improving the outcomes of one of your biggest cost centers. I am wearing my shocked Pikachu face right now. I was going to see if I could find some Amazon merch to pimp for this, but all of the shocked Pikachu merchandise there is super sus. Or is it suss? I cannot keep up.
It turns out that companies spend on coaching when their engineering organizations or products are on fire. It is far easier to get the blessings of the bean counters for reacting to a problem than it is to invest in proactive coaching that might keep you out of trouble in the first place.
Why is this true? It seems that there should be more appetite for proactive coaching rather than just reactive coaching in much the same way that people say, “An ounce of prevention is worth a pound of cure.”
I recently attended a CTO talk in OC. The speaker blew me away by describing how they upgraded their internal data platform using Databricks. At the end of the talk, I asked her where she had learned the soft skills needed to get approval for this project. She attributed it to her career coach, which she paid for alone.
I decided to ask another question at the end of this talk, similar to one I asked during an engineering presentation at GDC in March. I asked the audience how many people have coaches or mentors. In both cases, far too few people put up their hands.
I was disturbed by that. Many people blindly trust their managers to look out for their careers. I have had engineering leaders with incredibly scarce mindsets at some companies where I have worked. It is dangerous to trust your own potentially abundant success in the hands of a zero-sum game thinker. Unfortunately, I am speaking from experience here. The vast majority of times I have had an engineer as my boss, they were generally very poor leaders. Early in my career, I confronted some of them with their poor thinking (I was not thinking in terms of abundance and scarcity until at least 2012). Later in my career, I would gently suggest abundant alternatives to find what justifications they claimed to adhere to their course of action. In either case, I seldom convinced anyone to adjust their thinking.
Coaching people on your teams is possible if you are diligent about it. You just have to be very mindful about cannibalizing your coaching in favor of business outcomes. As a coach to people I manage, I often have to include caveats to ensure they know there is sometimes a lack of alignment between these two things. Sometimes that lack of alignment is not subtle.
If your boss is tunneling too much into their own work outcomes and objectives to be an effective coach for you, it may be time to reconsider where you work. Many companies offer lifelong learner paths that include coaching resources and learning opportunities.
Alternatively, see if your company will pay for an external coach to help improve your outcomes. It does not hurt to ask. If they say no, you might be able to find a coach willing to give you a “stingy company” discount that takes into account that your personal budget for self-improvement is smaller than the line items in the L&D budget for the company.
Give me a shout if you think that is interesting. I coach people myself, and I am connected to about half a dozen other coaches right now who have tremendous engineering leadership experience and can help you ensure you are maximizing your career potential.
This is enough of a sales pitch that I do not wish to sully it with an Amazon Affiliate link.
See you all next week!
I make a point of trying to unplug on Saturdays. Part of this ritual includes getting my steps in—of which I try to get twenty thousand while I am at it. At least sixteen thousand of them come from a single hiking exercise where I walk to a nearby regional park and walk in a loop on some rather rattle-snakey trails before walking home.
Imagine my surprise when I spotted an interesting-looking fence post on the way to the park that appeared much shorter than its peers. My photograph does not do it justice. The exciting part about this repair job on the fence is the blog post opportunity it created for me.
This picture lets me ask you: How do you decide how much time and resources to spend fixing issues in production?
In an ideal world, you would want to replace this shortened pole completely. That means you would need to dig up the pole, transport a replacement pole to this location which is nearly one hundred yards away from a nearby parking lot or road, and then somehow drive it successfully into the ground.
Two of these three steps involve some kind of machinery and/or transportation. You will need to bring the post to a nearby road and then have a machine of some kind that will drive it into the ground. You might convince someone to carry it from the back of a pickup truck to that location while you are at it. This is the work of two or three people, one large transport, and one pile-driver machine. If you were looking at the costs of this enterprise, you are likely well into the single digits of thousands of dollars now.
The alternative is for one person with a chainsaw and a power drill to cut a new groove further down the post and bore a hole into it to attach the bolt. This is likely about an hour of work and probably the work of one person with a small bag of tools.
It does not look perfect, and almost nobody will care. It will do the job the previous fence did.
One of the roles of engineering leadership is to decide whether to do the patch job on a pole with a quick fix like this or a deeper refactor that costs more time and resources to solve the issue more completely. Most of the time, the deeper fix to an issue like this is best done after thinking about it more deeply and probably modifying two or three other problems simultaneously.
I am quite pleased with myself. A passing observation on my extensive weekly hike purchased a week-long backlog extension for my blog. I have a reasonably deep queue of subjects to entertain you all, and every time I can extend it, I feel like I have accomplished something.
I feel like celebrating. What better way to celebrate than to order a delicious boxed set of Tortuga Rum Cakes? Please click on this affiliate link and purchase this amazing assembly of delectable treats to participate in the festivities!
As a parent, the number one question I get asked by other parents is, “How do I get my kids to have a job like you have?” It is a great question. I have a horrible answer that scares most of them away. “You have to love mathematics and problem-solving.” Modern society has instilled a fear and loathing for mathematics and hard work in our children through popular media. I believe these are essential cornerstones to a successful knowledge worker career. While I do not love his books much, Andrew Friedman gets this much right:
“In China today, Bill Gates is Britney Spears. In America today, Britney Spears is Britney Spears — and this is our problem.”
I mean, the dancing is okay, and the music to me is kinda mid, but you get the idea, right?
So, how do you embark on a career as a software professional?
To bastardize another popular quote, this time from the movies:
“Show me the source code!”
And I put the word source code, where it used to say money.
Now that I have bombarded you with not just one but two trite internet quotes, I will proceed to dispense with my own wisdom.
There are four paths to a career in software development. They have varying costs, take varying time, and have varying degrees of success.
The first and most traditional way to get into software development is to take a four-year college degree program specializing in computer science or computer engineering. It takes four years and costs tens of thousands of dollars. I was fortunate to get into a co-operative education program where I could work between semesters and get paid. This enabled me to get through my degree with low student debt. It is harder to do this now than it was when I went to school. The costs are accelerating, and the barrier to getting accepted into a four-year program has never been higher. I am not certain that if I were just finishing high school today I would even get into the University of Waterloo!
The second way is to take a boot camp program. You can go to many places to get a four- to twenty-week boot camp. This takes less time than a college degree and is less expensive. I believe most of these are less than the cost of one year of college. There are remote boot camps like the Chegg Skills program and local businesses that specialize in this, like LearningFuze. I have met with candidates from both programs and found they have reasonable day-to-day skills for a junior software developer. I have hired a few people from these programs as well.
The third way is the hardest for most people. You can sit down and start learning it on your own. There are a variety of tools and videos on the Internet to help you become a software developer. I have worked with half a dozen self-taught software developers, two or three of whom are among the best software developers I have ever worked with. I have a limited amount of advice on what resources to use to become a self-taught software developer; it has varied over the years. All the people had high innate math skills and intense curiosity and grit. This takes between six weeks and six years, depending on the individual.
The fourth way to become a software developer is the one I have seen the least. You can find an existing software developer and attempt to become an apprentice. I am mentioning this because I have attempted to find a software apprentice a few times without success. I have met many people who expressed a strong interest in pursuing a career in software development, and when presented with an option to help get them there from here, they wrote more excuses than lines of code. A friend of mine is attempting this with one of his friends right now. This is on par with the time frame for a boot camp but without the cost. It requires knowing someone who has the skills as a senior software developer committed to helping you get there from here. I will update you all when I hear back from my friend on how this went.
This is a short post today, and hopefully a good one. Thank you for being patient. I know this blog post generally comes out earlier in the week. We have back-to-school stuff happening, heat waves, and of course, World of Warcraft: The War Within all happening at once this month and I have been battling with time on all three fronts.
That being said, if you know any late-night West Coast Havoc Demon Hunters looking for a raid guild, hit me up. Our raid team needs one.