In the last few years, I've talked with hundreds, if not thousands, of software developers.
What I've learned: there's a HUGE gap between what developer-influencers are writing about, versus the daily reality of most developers. BUT PEOPLE DON'T TALK ABOUT THE OTHER STUFF. 1/
A disproportionate amount of writing and tooling comes from companies like Facebook, Netflix, LinkedIn, Google, and Amazon. Many people assume there's a trickle-down effect: great engineers at companies with money to burn come up with good solutions to problems everyone has. 2/
But the solutions that engineers at a Netflix or LinkedIn or Facebook come up with aren't for the vast majority of software shops: they're often best for big companies that can afford to set a high engineering bar, that can afford large infrastructure teams and ops teams. 3/
SO MANY of the software teams I've talked to have sheepishly told me that their software practices differ from the recommended standard.
When I listen to why, it makes a lot of sense for their needs: different org size, different eng team makeup, different shipping cadence. 4/
Many assume it's a matter a time before certain practices permeate the entire software industry.
But if you have piles of legacy code and/or limited engineering bandwidth, it absolutely does not make sense to redo your entire system using something that "makes sense." 5/
To start shedding unattainable software standards, let's:
🛑 Stop thinking of software as homogeneously represented by a small number of unrepresentative companies
🗯 Start being more honest about "real software process"
🛠 Demand more solutions to the real problems!!
end/
• • •
Missing some Tweet in this thread? You can try to
force a refresh
When I had been on the other side of the process, submitting resume and cover letters felt like lobbing random stuff over a fence.
Here's a quick thread that might be helpful to people applying to jobs. 1/
There are two main things I look for on resumes: 1. evidence that someone gets stuff done and 2. the ability to communicate this to me.
More so than what companies someone has worked at, I look for bullet points and results. What did this person do and what was the impact? 2/
Here's what separates a good resume from a "pass" for me:
✔️ Clearly states roles and impact
✔️ Past experience either shows a cohesive career arc, or there's a cover letter that explains it
❌ Lots of words ("collaborated cross-functionally"), but I can't tell what got done
3/
A few months ago, as users started throwing more API traffic at the Akita client, we started seeing multi-GB memory spikes. 🙀
At first, we hoped for an easy solution. There was none.
This is the story of @markgritter's 25-day journey taming memory usage in a #golang client. 1/
@markgritter The first thing @markgritter did, as you would do in most languages, was to profile the system for obvious bottlenecks.
There was one, in the #gopacket reassembly buffer. Memory was persisting even though it wasn't getting used.
Mark fixed this, but the problem persisted. 2/
@markgritter At this point, the team and I weighed possible next steps.
Since #golang is memory-managed (2x memory overhead no matter what 🙀) and does not expose much control over the garbage collector, we were worried that it was not possible to be able to get memory usage low enough. 3/
Been talking with a lot of people who are burned out at work right now. I got quite burned out at the end of college and in the middle of my PhD. Today, I work way more than I did back then and am able to feel really fulfilled. Here are some lessons that helped me get here. 🧵 1/
First and foremost, it's helpful to recognize that you're burned out. Are you feeling less creative? More irritable? Over the years, I've learned to recognize micro-burnouts (from "I need lunch" to "I need a vacation") and I like to believe that's kept me from macro-burnout. 2/
Working sustainably is key to preventing burnout. For me, i's not about limiting hours but about building in recovery. The recovery needed depends on the intensity and duration of the work. If I go for longer without recovery, the recovery will need to be longer/more involved. 3/
Every now and then, I see a thread about how functional programming languages are The Way, wondering why they aren't more popular.
A big problem is that people talk about functional programming as The Way for Everything. FP has its place. All tools have their roles. 🧵 1/
The elegance of functional programming makes it an appealing "silver bullet" candidate.
But here are the domains where FP really shines: 1. Programming education 2. Prototyping language features and analyses 3. Domains where you're mostly specifying transformations
2/
I fell in love with Scheme and SML in undergrad. I taught myself Haskell and extended it for my senior thesis. In grad school I worked in Haskell, then OCaml, then Scala.
But by the end of grad school, I was mostly using Python.
Why aren't there more startups based on programming languages and software analysis?
There's definitely a need for SOMETHING, as developers have so much pain.
I was recently on a panel where someone asked this question. I didn't have time to answer then, so here's a thread. 1/
There's often a gap between the creators of "principled" programming tools and the needs of working developers.
There are two common technical assumptions: 1) code correctness is a top priority and 2) it's possible to understand the whole system.
Often, neither hold. 2/
In programming languages and formal methods there's the dream of "soundness:" if there's a bug, the tool will find it.
People don't want to know all of their problems. They want a prioritized list of problems that matter. This technical goal is often at odds with user needs. 3/
@kaifulee Jeannette Wing, who co-developed the Liskov Substitution Principle. Leader in formal methods research. Head of @SCSatCMU 2004-2007 and 2010-2012.