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
 

Keep Current with ☠️ Jean Yang 🥀

☠️ Jean Yang 🥀 Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @jeanqasaur

22 Oct
Been going through a lot of resumes recently.

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/
Read 7 tweets
23 Sep
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/ Memory spikes in the Akita CLI
@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/ Profile showing bottleheck in reassembly
@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/
Read 10 tweets
15 Sep
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/
Read 6 tweets
6 Aug
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.

Here's what happened.

3/
Read 9 tweets
14 Jul
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/
Read 7 tweets
13 May
Taylor Swift as notable #AAPI computer scientists. 🧵

Andrew Yao, 2000 Turing Award Winner. Known for proving Yao's Principle. See also: Yao's Millionaire's problem.

#AAPIMonth
Raj Reddy, winner of the 1994 Turing Award for pioneering work in artificial intelligence. Mentor to @kaifulee.

#AAPIMonth
@kaifulee Jeannette Wing, who co-developed the Liskov Substitution Principle. Leader in formal methods research. Head of @SCSatCMU 2004-2007 and 2010-2012.

#AAPIMonth
Read 6 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(