I don't think I want my next promotion (yet)
Often folks think that chasing the next promotion is the best thing to do, but sometimes you should just enjoy where you are..
Often folks think that chasing the next promotion is the best thing to do, but sometimes you should just enjoy where you are..
This is an awesome HN thread on all the ways blogging have improved the lives of developers around the world. It’s brimming with statements like:
I’ve been blogging since 1998 and can trace every major step forward in my career to my blog.
The best time to start your developer blog was 1998. The second best time is right now.
Justin Searls dives deep into whether AI tools like ChatGPT actually threaten knowledge worker jobs and provides helpful ideas around what to do about it.
Having spent months programming with GitHub Copilot, weeks talking to ChatGPT, and days searching via Bing Chat as an alternative to Google, the best description I’ve heard of AI’s capabilities is “fluent bullshit.” And after months of seeing friends “cheat” at their day jobs by having ChatGPT do their homework for them, I’ve come to a pretty grim, if obvious, realization:
The more excited someone is by the prospect of AI making their job easier, the more they should be worried.
Hired CEO, Josh Brenner:
We create this report every year to help talent professionals and software engineers understand the hiring climate, as well as what’s top of mind for employers and engineers.
Here’s some of their key findings:
There’s a lot to digest here. Worth a read, especially if you’re on the market.
I was a programmer for 12 years. I then switched to support and people management for 12 years. I now want to go back to programming for the rest of my career. I started working at Zed Industries on January the 17th, helping build the Zed editor and be a Rust programmer wannabe. End of June is going to be the judgment day. Will I remain part of Zed?
That’s right. I have a six month contract with the company my ex-GitHub colleague founded. They are trusting me to become productive in Rust within 6 months. With no prior experience in Rust, this feels like a Herculean feat. The interesting part is that I abandoned a high-paying job to do this. And by the end of the six month contract, Zed Industries and I may decide to part ways and still be friends.
And I am blogging about my experience so far. It’s a mix of personal learnings and small technical bits and pieces sprinkled here and there. But it’s mostly about my personal experience.
Manage your resume as structured data, in a modular fashion, within the comfort of your code editor, rendered your way and out of word processors. Here’s a quick 3 minute demo.
When we actively hire, our startup gets 150 - 200 applications each month. I read every single one of them. Sometimes, I’d talk to a candidate and see that what we perceived as their strongest aspects actually weren’t included in their resume. Occasionally, a candidate would tell me that they didn’t expect their resume to still be screened by humans – had they known, they would have written their resume differently.
The resume evaluation process is pretty much a black box for most candidates. And it is so because few hiring managers have publicly discussed this. I thought I should start the conversation.
Chip’s team mostly hires for infra and ML roles, so some of the advice here will be catered towards those positions. Still, if you’re on the job market you’d be well-served by spending 15-20 minutes reading this post and tweaking your resume where applicable.
I’m currently working at a top tier investment bank as a software engineer. I’m an insignificant cog in a machine that skims the cream from the milk. I’m earning the most money I’ve ever made and yet I’m the least fulfilled I’ve ever been.
Right now in the UK and across the world, things are uncertain. Companies are laying workers off, there’s a cost of living and energy crisis. I’m excruciatingly lucky to have been in the right place at the right time to develop the skillset I’ve got. In times like these every signal is telling me to stay on the path I’m on, enjoying the comfort and safety of a high paying job.
I’m not going to listen. I’m quitting and I’m leaving this place. I’ll see you in the mountains.
After this post blew up, Seán wrote a follow-up on what quitting the rat race means to him.
Burnout has reportedly reached a critical point in the software developer circle since the onset of the Covid-19 health crisis. A recent study by Haystack Analytics, a company specializing in productivity of engineers, found that 83% of software developers suffer from burnout. The main reasons given by the latter to explain this exhaustion are high workload (47%), process inefficiency (31%) and lack of clarity of objectives and targets (29%).
That few?! 😏
While obtaining a job internationally may seem daunting, this guide will walk you through all the steps you need to find and secure a developer job abroad.
In this article, I share how how to prepare your resume for getting a developer job abroad, how to search for international opportunities, application strategies, important considerations to make when applying, the do’s and don’ts of successful interviews, and more!
Rachel Stephens, trying to reconcile the claims that the tech industry is vastly overstaffed with other claims of vast resource scarcity:
Both things can be true: it’s not a clear over- or under-staffing problem. It’s a problem of proportionality. There can definitely be organizational bloat… At the same time, there are also areas in tech that remain chronically understaffed and under-resourced: OSS project maintainers, people working on-call support, and people writing documentation to name a few.
An interesting analysis with a much-needed call for kindness to our fellow nerds as they face these tumultuous times.
And (I can’t believe I’m writing this, but the jokes about Twitter layoffs in particular keep coming at a surprising rate) be kind to people facing layoffs. Losing your job is awful in the best of circumstances; going through it in such a public and charged situation must be emotionally grueling. Be kind.
According to this, 757 companies have laid off 104,791 employees thus far in 2022. Absolutely brutal.
Just over a year ago, I did something quite “out there”, even for me, and I posted my salary history publicly. This was accompanied by a blog post to explain why I was doing it, and it’s certainly been popular.
When I first posted it, I made a note to myself to come back in a year, and see whether anything had changed, as well as to look back on some of the events that happened immediately after my posting, as it certainly made life interesting in the month or so following the post.
A lot of ink has been spilt over the years trying to elucidate the divide between junior and senior. Miłosz Piechocki makes the distinction this way:
Junior Engineers care about writing Software. They value code quality, employ best practices, try to adopt cutting-edge technologies. They invest a lot of time into learning new technologies. To them, the ultimate goal is to create elegant, performant, maintainable software.
Senior Engineers care about building Systems. To them, creating software is just one of the steps. First of all, they question whether the software needs to be built in the first place. They ask what problems would it solve and why it’s important to solve them. They inquire who will be using the software and on what scale. They think about where the software would run and how they’re going to monitor whether it’s working properly. They also decide how to measure whether the software is actually solving the problems it was supposed to solve.
He goes on to describe how hard it is to build Systems and lists activities that are part of that process.
Don’t stress, we all break production. These are the tips I wished I had. Not which framework to learn, or how to ace that programming interview (all useful!), but what to expect when you land your first software job.
This framework allows software engineering managers to have meaningful conversations with their direct reports around the expectations of each position and how to plan for the next level in their career ladder.
This year marks 15 years since FizzBuzz was popularised as an interview tool for developers. I’m a big fan and have watched over 100 candidates try their hand at my version of the task. In today’s blog post I’d like to take a moment to celebrate what makes FizzBuzz so helpful, discuss some common patterns I’ve observed in the many attempts I’ve witnessed, and finally explore some tweaks that can be deployed to keep the challenge fresh.
Tom’s version of FizzBuzz is a pair programming task that follows strict TDD:
In proper pair programming style, the candidate is encouraged to discuss their approach with the interviewer. Likewise, they are free to use any online reference materials if they forget a method name or some syntax.
In this post he shares 3 common variants of the challenge including one that requires a pair of Azure Functions?!
James Hawkins, after being on a team that’s interviewed over 725 people:
It’s normal for candidates not to ask harder questions about our company, so they usually miss out on a chance to (i) de-risk our company’s performance and (ii) to increase the chances they’ll like working here.
Does the company have product-market fit? How much runway does the company have? Does their spending look within reason? What’s the culture like? And more tough questions that you really should be asking before accepting that offer.
Wise words from Andy Brice:
When I was a child I assumed that all the adults running the world knew what they were doing. Now that I am an adult, I am under no such illusions…
I’m going to let you in on a little secret. Most of us who are running businesses had no real idea what they were doing when they started, and still struggle with decisions now.
I tell people this all the time when they ask me for advice. I’ll still give them my advice. But it comes with the disclaimer that I really have no idea what I’m doing. 😆
I love when software engineers share their career/life choices and the reasoning behind them so others can benefit from their perspective, like this one on bucket filling:
Somebody once described balance to me as three buckets filled with water. One for career, a second for physical health, and a third for social and family life. At any point, one bucket might be running low. But as long as the overall water level is high enough, things should be fine.
Scott’s choice to join a startup seems odd given his reason for leaving Google, but:
So: am I happier? Undoubtedly yes.
I work more hours. I’m more likely to be working in the evening or on the weekend now. But what I do makes a difference that I can see. Progress feels 10x faster.
Most surprising is that I have more energy. It’s easier to find motivation to get back in the gym. I have more energy in social situations.
Working more hours sounds like tipping the work/life balance in the wrong direction, but excitement about your work certainly changes the calculus. He’s happier now, so that’s great!
Some years back I applied to join IBM’s grad scheme, there was a peculiar stage to the process I’ve not seen elsewhere. It was during the onsite day, where a batch of 20 or so applicants were put through various tests in an IBM office. They called it the “group test”; around 8 of us were led to a room and asked to solve a puzzle together.
You can probably see where this story is headed… (see also)
Eric Jang was recently on the job market (finally landing at [Halodi Robotics])(https://halodi.com/) and in this post he shares his process and view of the job market today. He also has some insights on where it’s headed. In brief:
In the future, every successful tech company will use their data moats to build some variant of an Artificial General Intelligence.
Sounds like Jacob Kaplan-Moss isn’t the only hiring manager who’s keen on the reverse code review:
When hiring developers, there are many things we are looking for, but over the years I have found that raw coding ability is easily the most important quality to look for. I can quickly train a person to have knowledge in some domain, but I’ve never seen raw coding ability come from anything other than personal commitment to extensive and deep practice. Because of this, I have found that some methods work better than others to discover talent.
… instead of writing code, consider instead having the candidate read existing code and talk about what it does and how it works. This offers some powerful advantages:
The advantages in brief:
Click through for the details and how to put this in to practice.
Well, that is the single largest expense we have. If we want to optimize anything in our discipline we should look at this part first. We talk often about how we build systems, but how often do you talk about how you spend the “figuring out” time? If we do not talk about it, it’s not explicit. If it’s not explicit, it does not get optimized.
In addition to the author’s suggested solution to this problem allow me to add: developer retention! Nobody has more to figure out in a system than the people who just joined the team. Cut down on that (via better compensation, workplace satisfaction, etc.) and you cut way down on that oh so expensive “figuring out” time.
For many software folk, we prefer our networking to have TCP handshakes, not literal (or even virtual) handshakes. If that’s you, this guide might help you get over the hump:
Here’s the truth: you can get what you need from these events without being awkward or creepy. Whether that’s job leads or important connections, there is a well-defined, time-tested way to accomplish this. It will push your limits, but it won’t leave you feeling gross inside. And the more you do it, the better you’ll get at it.