After the first tech job
lowlyswe.substack.com
lowlyswe.substack.com
I don't think this is actually true. Employers don't give a crap about your side projects, what you do in your free time, or what you learn at the weekends. Many don't even want you to learn things in your job. The reason it's so widely believed in our industry is four-fold;
- people who are "Twitter famous" devs often work as developer advocates for businesses, and spend their work days building small projects to demonstrate things. Then they talk about them but never mention that they're work projects. Their audience thinks "I could never get to build that in office hours, must be a side project!" and extrapolate from there that getting to be a rich and famous dev advocate means working on weekends.
- devs involved in hiring say they want to look at Github repos. I've been hiring devs for the last 15 years and while I do look at repos if they're available I still interview loads of people who don't have them. In fact, to be honest, having public repos is more likely to push me to rule someone out rather than arrange a chat. Most people's public repos are examples of very bad quick hacks, starter projects with no additional work, or things so poorly documented I can't even tell what they are.
- we like making side projects and need an excuse to spend time on them. When your partner or kids or parents are nagging you to do something being able to stress that our career will wither away to nothing if we don't spend time on something on Sunday night is useful.
- it's a route out of a bad job. If you're working with tech you don't like, at an employer who refuses to give you a training budget, and you don't have any opportunity to learn things in work time, then side projects are an obvious alternative. A better alternative is to find a job where you can grow. An important thing to note about this is that there are a ton of skills that are really hard to learn at home on a weekend (running meetings, talking to clients, using focus groups, mentoring juniors, writing clear docs, etc). Being a dev is about much more than coding after all.
For me, Github/personal projects have not been a useful signal either way, but it is apparent in recentish years that the advice has been to have one regardless.
It just happened rarely. 95% of github profiles held almost nothing of interest.
Impressive github + well known employers + gregarious/outgoing as a combination also always basically signaled that the candidate wasnt going to be within budget.
side projects’ intended audience isn’t future employers. It can be anything the creator wants to hack on just because.
> Most people's public repos are examples of very bad quick hacks, starter projects with no additional work, or things so poorly documented I can't even tell what they are.
lol ok. Having worked at several corps generating hundreds of millions of dollars of revenue, most of them have been powered by the gnarliest of hacks duck taped together and kept alive by armies of pitiable engineers with a pager. Your expectations are wildly out of touch with how most software companies operate.
On the contrary, I write code in my spare time a lot. I have a ton of GH repos, CodeSandbox things, Codepens, etc. I tinker with things all the time. I'm just aware that others don't so I try not to let my own preferences bias how I hire people. Missing out on a great candidate because they're not like me would suck for my team. Plus, I'm also aware that people's 'free time code' often isn't representative of how they write code professionally. I wouldn't want to be judged on mine...
Your expectations are wildly out of touch with how most software companies operate.
I've run a software company. I've worked at a lot of them. I'm very aware of how much things are held together with duct tape and undocumented YAML files. I don't see how that would impact how I'd review someone's public GH commits though. The company they work for might be operating a codebase that's one commit away from catastrophe, but it might not. I don't get to see that code so I can't really use it as a reference.
Of course, this will also cause people on HN to shout at you for making things too complex, but you can't have everything.
http://www.nichesoftware.co.nz/2021/07/10/magpie-driven-deve...
There are too many good people out there who don't have interesting public github repos. It isn't a decisive signal although it might help a resume stand out from the crowd.
That sounds like a good thing? Looking at the quality of someone's public work lets you rule out more candidates who are not a good fit.
A great example is the projects I do to learn things or for fun; such as this awful ruby port of a BBC Basic game from the 80s which does _nothing_ the right way: https://github.com/dijit/SpyQTest-rb/blob/master/spyqtest.rb
The constraints are fewer on side projects, the motivations are not the same.
I am not certain that I'm amazing at my job, I'm definitely decent enough to be employed for 15~ years, but the gulf that exists between my GitHub repos and code I write for my employer is extreme enough that I'm relatively certain that if I was judged on my GitHub profile alone I would not get jobs; and if my proprietary code were open it would lead to jobs.. so *shrug*
More generally, it would be helpful if you explained more why you disagree. This comment and the paragraph you reference are both devoid of any actual explanation for your opinion beyond "it worked for me", while the commenter you're replying to has clearly thought things through.
* What if one spent a year doing the bare minimum at their job because their creative energies were wrapped up in their side projects, while the other took the lead on important tasks at work?
* What if one spent a long time working on side projects that use arcane technology, while the other worked at a job that uses the same tech stack I do?
* What if the one who worked on the side projects is distractible and never finishes anything while the one who didn't is focused and get stuff done?
* What if the one who works on side projects doesn't get along well with others, while the other one avoids side projects because they prefer to be on a team?
* What if one did side projects because their job bored them to tears, while the other was a key player on a small team and learned a ton from their job?
The point is, side projects are just one signal among many, and they're far from the most important signal. This is important to keep in mind when strategizing your career, because it means that there are other things that are valuable to focus on; it's not just side projects or bust.
The one who interviews better, and who sounds like they'd be a better fit for the team. If one of them has been learning the things the team uses then that will shine through on their technical interview and coding test. If they've been learning something that's not used then it won't make any difference and won't put them any further ahead than the candidate who spent their spare time doing other things.
Anecdotally, and this is just me rather than something that applies broadly in tech, but I don't want people on my team to work (or learn, or whatever) 16 hours a day. I want to work with people who are fun, interesting, and have interests outside of just working all the time. There's few things I find more tiresome on a Monday morning than when the PM asks "how was your weekend?" having someone on the team who never has anything to contribute. Those people are boring, and they make the rest of the team less willing to engage with one another.
Coding is a team sport. If you're doing your best work on your own at 2am learning something new then you will not do well in many companies.
Your stories show a less traditional but just as valid approach, and I think it's an important thing to show people that you can get into tech and still make a decent living even if you're not one of the stereotypical HN FAANG crowd. The whole world isn't Silicon Valley, in spite of what you often see here.
Almost all my changes were because either because of change in management or job getting boring. But networking and knowing people played a huge part in ever move.
A huge break for the company owner! You were clearly able to ship things, and he was able to just hire you, instead of having to go through a long and painful process with the recruiters.
> Still didn’t really know what I was doing though.
I'm pretty sure no one knows what they're doing...
Really not trying to be dismissive here, and I realize it was only the setup not writing the full software, but there's probably still a zillion things that could be missing / go wrong if you don't really know what you're doing (which is the case if you need a tutorial and help from Discord at every other step, let's be honest). "Failing forward" may work for consumer-facing web startups where nothing really sensitive is on the line, but if your software can physically accelerate two tons of metal to 100mph, it's a bit of a different game.
8 or so years ago I used to frequent a meetup only because it was hosted at our office. I figured a chance to hang with a few coworkers I liked and a free beer was worth it.
I ended up learning scala.
During those meetups we kept getting these really awesome presentations about concurrency and things. At the time a company who was just bought by a really known guy would present their solution to handling massive amounts of traffic. To us Java people we brushed it off as we’ve been handling volume for a while with Spring and stuff.
Anyway, what I’m saying is. Keep going to the meetups for the tech you are interested in learning. You WILL learn something. Then, when you ask questions (because you won’t be able to help yourself), you’ll end up networking. Strange I know.
Someone who goes out into the world, improves themselves, and tries to show that to other people will have more opportunities to be lucky than someone who does none of these things. Obviously both people can strike out, but the person who never tries is way less likely to succeed.
In other words, you’ll be “lucky” if you put yourself in a position to succeed whenever opportunity comes.
This is the painful reality that anyone self-taught who wants to break into this industry will have to face. I spent my entire 20s grinding endlessly. Constantly learning, constantly coding, working 18 hour days nonstop. I studied CS theory, engineering principles, frameworks, OS internals, etc., etc., etc. to the absolute exclusion of anything else in life. Now at 32, I see my peers all married with families and personal lives. A life that I do not, and probably will not, ever have at this point because of the sacrifices I made back then. But I am also lightyears ahead of them technically. At my current job I've been promoted 3 levels past the midlevels I started with 4 years ago.
Life is full of decisions, and unfortunately attaining excellence requires commitment, dedication, and focus. You can do alright otherwise, but if you really want this and have the aptitude to reach the top, it will consume you.
At the moment, I'm a bit younger than 32, but I almost consider relentless tech grinding to represent a silly sort of immaturity, or at least a bit confusing. As in "You seriously haven't found something else to do with the little spare time you have?", not that I'd say that.
For the reasons above, I think it's crucial that people take extended breaks every few years to really think about whether they enjoy what they're doing, or if they're just doing it because they have the ability and otherwise kind of fell into a certain path.
Most people I know, if they are even married, are having kids around 35 after getting married in early 30s.
Getting stuck in “career” mode consumed the majority of the last decade. Self taught is not an easy path, but my life is much better than it would have been had i continued what i was doing before getting into tech.
Now i just want to play an instrument and sit outside. :)
That said, it's simply not true that getting to a senior staff-level, or even director-level, position in tech requires busting your ass with 996 and no personal life. It might take a few extra years, or switching jobs a few times, but the higher end of the ladder is one with extremely diminishing returns on your personal time input. In certain positions your value is your ability to pattern match with previous experience, and such experience won't come to you any faster when you sit at the computer for a few more hours.
And if you go past that, into the c-suite, it's full of people who have a lengthy resume/connections and leave work at 4pm to go pick up their kids.
I agree with your comment really. It doesn't say anything about future potential or paths you could go down. Simply that to get where you have you had to act a certain way.
I know not your intents. If you like where you are, good job. If not, act different to get different.
That's with many things, not just with a tech career. Jordan Peterson* mentions this many times: there are people that just work for the sake of working and then become miserable.
* I do not endorse every opinion of him, but I find this opinion of his great food for thought. I especially have issues with his Christian and conservative side. He's one of the few people that can break my filter bubble while I can also listen with interest to what he has to say.
I think you've decided that you don't want a family/etc. any time soon. No problem with that. But the other side of life that isn't about work requires lots of commitment, dedication, and focus. It doesn't work well if you don't put in the time and the effort.
So, I'll add one word to your list of excellence-attaining requirements: balance. You'll need it if you ever want more than just work. And you also might realize that a singular focus on one thing is not worth as much as you thought. I don't think you made the better decision among the potential universe, you just made a different decision.
Curious to hear more from you about what you want beyond work.
Because the fashion industry never changes ???
Someone's hair changed quite a bit.
I think at any age/level you can get bit by that hacker ethos, and it seems like you got it ;)
And thank you!