Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dev blog, needs log and maybe some editing. #2025

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

robotdan
Copy link
Member

No description provided.

site/_posts/2023-03-10-growing-is-hard.md Outdated Show resolved Hide resolved
site/_posts/2023-03-10-growing-is-hard.md Outdated Show resolved Hide resolved
site/_posts/2023-03-10-growing-is-hard.md Outdated Show resolved Hide resolved
site/_posts/2023-03-10-growing-is-hard.md Outdated Show resolved Hide resolved
site/_posts/2023-03-10-growing-is-hard.md Outdated Show resolved Hide resolved
site/_posts/2023-03-10-growing-is-hard.md Outdated Show resolved Hide resolved
site/_posts/2023-03-10-growing-is-hard.md Outdated Show resolved Hide resolved

The first is that the new team feels a sense of community as they all start from zero together. They do not have to compare their skill set or knowledge of the product with someone that has been doing it for 10 years, and instead can compare to another that is learning the same things.

The second - which is most exciting to me - is that we are now filling the tub four times as fast!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The second - which is most exciting to me - is that we are now filling the tub four times as fast!
The second - which is most exciting to me - is that we are now filling the bathtub four times as fast!

Also, if we're going with math, it's only 3 times as fast.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I sort of wanted to say tub to make it more slang.


Seeing mistakes in hindsight is not difficult. I would do many things differently given the opportunity.

One of our biggest mistakes is thinking we could not afford to hire senior engineers. It can be difficult to hire these engineers early in a company because their salary requirements will likely be more than you pay yourself. But the reality is that they can produce 5-10x of an entry level engineer, and their salary not even close to 5-10x, and more likely 2x.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a fan of the productivity comparison. Partly because I think the "10x engineer" thing is dumb.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't so much a "10x-er" statement - but the reality of what an experienced engineer can do in contrast to a brand new engineer. Open to better ways to say it -but there certainly is a difference in productivity.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd anchor this in personal experience, and maybe leave off the numbers (which I assume are anecdotal). Maybe something like:

But the reality is that a senior engineer can get up to speed more quickly and therefore can produce far more value (through code and processes) than someone with less experience. The value they bring is far more than the extra cost. For example, we had a senior engineer take on a task similar to <X>, whereas before a less senior engineer had a hard time doing a similar task.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about if you are going to call out anyone, so maybe ignore the 'for example' above if you can't do so without saying unkind things about someone.

site/_posts/2023-03-10-growing-is-hard.md Outdated Show resolved Hide resolved
robotdan and others added 7 commits March 10, 2023 16:44
Co-authored-by: Spencer Witt <spencer@fusionauth.io>
Co-authored-by: Spencer Witt <spencer@fusionauth.io>
Co-authored-by: Spencer Witt <spencer@fusionauth.io>
Co-authored-by: Spencer Witt <spencer@fusionauth.io>
Co-authored-by: Spencer Witt <spencer@fusionauth.io>
Co-authored-by: Spencer Witt <spencer@fusionauth.io>
Co-authored-by: Spencer Witt <spencer@fusionauth.io>
@mooreds mooreds added the content large piece of content label Mar 11, 2023

The downside is that you rarely develop the same level of experiences and skill that you would by sticking around, learning to work through conflict, mastering a code base and learning how to stay productive in spite of company politics.

Unfortunately this doesn't seem to be the sentiment shared by many engineers.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Unfortunately this doesn't seem to be the sentiment shared by many engineers.
Both of these are viable career options.
I have found digging deeply into a codebase and staying at the same company to be great for my career. Unfortunately, this doesn't seem to be the sentiment shared by many engineers.

Unfortunately this doesn't seem to be the sentiment shared by many engineers.

### The problem
By the time an employee is beginning to produce and become competent - they have one foot out the door looking for their next adventure.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
By the time an employee is beginning to produce and become competent - they have one foot out the door looking for their next adventure.
If an employee is at a job for only a year, by the time they are beginning to write great code, deliver features, and understand a complex codebase, they have one foot out the door looking for their next adventure.

One report shows an average tenure in big tech is between 1.1 and 3.2 years.[^1] The US Bureau of Labor and Statistics report a nationwide average of 3.8 to 4.3 years which is not limited to the software industry.[^2] Regardless of which statistic you use, it is hard to argue that average tenure in big tech is short, and almost certainly lower than the average across all sectors.

### Bye, Felicia
Switching jobs means new experiences, more money and a change of scenery. This can be very appealing early in your career and can help you level up quickly.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Switching jobs means new experiences, more money and a change of scenery. This can be very appealing early in your career and can help you level up quickly.
As a developer, switching jobs means new experiences, more money and a change of scenery. You can gain a wide variety of experiences, and each time you learn a new environment or system, you get an understanding of the tradeoffs and benefits of different setups.
This can be very appealing early in your career and can help you level up quickly.

### Bye, Felicia
Switching jobs means new experiences, more money and a change of scenery. This can be very appealing early in your career and can help you level up quickly.

The downside is that you rarely develop the same level of experiences and skill that you would by sticking around, learning to work through conflict, mastering a code base, and learning how to stay productive in spite of company politics.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The downside is that you rarely develop the same level of experiences and skill that you would by sticking around, learning to work through conflict, mastering a code base, and learning how to stay productive in spite of company politics.
The downside of switching jobs regularly is that you rarely develop the experience and skill that you would by sticking around, learning to work through conflict, mastering a code base, and learning how to stay productive in spite of company politics. There's a rigor in living in a project for years, as you see it evolve over time and can learn when architectural choices add flexibility and when they constrain. Sure, you can learn that from books, but seeing it in real life drives home the importance. Additionally, when working in an existing code base, you gain humility. There's nothing quite so humbling as fixing a bug you introduced a year or two ago: "what on earth was I thinking!".

### The problem
By the time an employee is beginning to produce and become competent - they have one foot out the door looking for their next adventure.

There are various ways to overcome this problem.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
There are various ways to overcome this problem.
This is an issue, because you want employees to be productive for years, not months. There are various approaches to solve this problem.


Seeing mistakes in hindsight is not difficult. I would do many things differently given the opportunity.

One of our biggest mistakes is thinking we could not afford to hire senior engineers. It can be difficult to hire these engineers early in a company because their salary requirements will likely be more than you pay yourself. But the reality is that they can produce 5-10x of an entry level engineer, and their salary not even close to 5-10x, and more likely 2x.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd anchor this in personal experience, and maybe leave off the numbers (which I assume are anecdotal). Maybe something like:

But the reality is that a senior engineer can get up to speed more quickly and therefore can produce far more value (through code and processes) than someone with less experience. The value they bring is far more than the extra cost. For example, we had a senior engineer take on a task similar to <X>, whereas before a less senior engineer had a hard time doing a similar task.


Seeing mistakes in hindsight is not difficult. I would do many things differently given the opportunity.

One of our biggest mistakes is thinking we could not afford to hire senior engineers. It can be difficult to hire these engineers early in a company because their salary requirements will likely be more than you pay yourself. But the reality is that they can produce 5-10x of an entry level engineer, and their salary not even close to 5-10x, and more likely 2x.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about if you are going to call out anyone, so maybe ignore the 'for example' above if you can't do so without saying unkind things about someone.


-----

[^1]: https://developerpitstop.com/how-long-do-software-engineers-stay-at-a-job/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd inline these.

It is sort of like filling a tub without plugging the drain. Unless you have great water pressure , the tub will drain faster than you can fill it. It is just difficult to get ahead, and you end up sitting cold and naked in the tub. The analogy does fall apart a bit at the end.

The result is that it leaves the technical founders holding the bag every time. This cycle repeats and can become demoralizing when the time and effort that is spent imparting the skills necessary to continue and grow the business are never preserved.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Remedies
Talk about possible remedies that don't involve hiring more engineers and why they didn't work.
documetnation
automation
pay more
make it a nicer place to work so people didn't leave

@@ -0,0 +1,63 @@
---
layout: blog-post
title: Building a team is hard&#58; part I
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is part 2 about the technology and domain? because those are worth addressing (our particular tech stack, java in general is not as sexy, the auth domain has unique challenges...)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure what part 2 is yet.. but figured it would be something. :-)

Copy link
Contributor

@spwitt spwitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked the meme for spelling of Felicia.

@mooreds
Copy link
Contributor

mooreds commented Mar 16, 2023

Is this ready to ship, @robotdan (apart from the header image)?

@mooreds
Copy link
Contributor

mooreds commented Jul 28, 2023

@robotdan if you give my changes your blessing, I can shepherd the rest of this through the publishing process. (I promise not to use the phrase "low key" :) ).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
content large piece of content
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants