Andrew Conner

Question for engineering leaders (managers, directors, VP's, etc): I'm curious about the current landscape of developer productivity analysis + management tools - things like LinearB and Jellyfish. Which tool, if any, are you using? Any opinions/pros/cons on the tool you're using (or the entire domain overall)?

21

When you work with as many systems as my team does - inevitably you're going to see some pretty terrifying projects. Badly structured code, glaring security flaws, and horrible workarounds to name a few. And while these are scary in their own right... ...what really scares me is that the non-technical people involved often have no idea they're even problems. And until the thing collapses, slows down, development time starts increasing for seemingly no reason, or they have a security breach, the people and teams that are cutting corners actually come off looking better in the short term because cutting corners lets you deliver faster in the short run. I've met business owners who are running systems that represent a MASSIVE risk to their business continuity and have literally no idea (or they do but can only describe it as a 'feeling' that something isn't right). So how do you solve this? Well unless you're genuinely interested in learning to code or following development best practices communities, then your best bet is to start with learning to ask the right questions of your team: -Does this new feature have automated test coverage? -What was the quality assurance process? -Was it code reviewed? Lazy and shortsighted teams will tell you steps like these "just slow things down" but if your project is anything but a prototype - these are actually the tools that enable you to develop at speed in the long run. And if you really don't know where to start then please reach out. If only so that one day when I have to integrate with your tool, I won't have to deal with a bunch of inconsistent data...

7

1 Comment

🛠️ Okay y'all, looking for advice: I'm running a handful of small apps for Build Carolina's Development Studio initiative. These are low-utilization apps for relatively small audiences. I'm leaning heavily on Rails at the moment but expect to bring on some JS-stack projects in the near future (likely Next, but I'm always open to the flavor of the week in JavaScript 😅) Here's what I'm finding for hosting: - I still know Heroku best, but I just don't trust them to not enshittify further. 🫠 Every new app here is a liability when Marc decides he needs another island or whatever. 💰 - I'm using a lot of Render and like their devex philosophy, but their pricing is weird (per-service + premium tiers? Pick one!), the big feature gaps in their platform have gone long-unaddressed, and their support has been poor. 🤖 - I'm experimenting with Fly.io: great pricing, but a weird mix of UI-vs-CLI workflows and segmenting project resources is unintuitive. I feel like I'm going to wake up to a huge bill because I accidentally over-provisioned something here. 💸 I'm curious what other folks are doing for small-scale artisanal app hosting in 2024+. Are we all running our own EC2 clusters? Is everyone just writing Next apps for Vercel? Maybe I'm just an old fuddy-duddy looking for a backend host in a static SPA world. 👴 ❓ Tips/tricks/tales welcome. Where are you hosting your lil' bytes right now?

13

39 Comments

Yesterday I had a great conversation with a friend and SRE at a very well known tech firm. I asked, "what do you wish you could know about your systems that your tools aren't currently telling you?" and the answer was pretty interesting. He talked about how hard it was to see the cascading effects of rate limiting and traffic shaping policies across a complex microservice application. He described the act of tuning limits and guessing heavily about the downstream side effects that might fix one issue, but impact other services downstream. This resonated with me, as it highlights a growing challenge in our industry. As systems become more distributed and complex, the ripple effects of configuration changes become harder to predict and manage. According to a 2023 Gartner survey, 74% of respondents were using microservice architectures, and 23% were not yet, but planning to adopt a microservices in the future. What’s fascinating about that is that only 39% of respondents thought microservices were completely or mostly successful at being cost effective, or manageable. My friend went on to talk about how tooling is weak in these areas, they aren’t solving the problems of toil around tuning and configuring limits. That’s unfortunate because traffic shaping and rate limiting are not just about protecting your systems from overload; they're about ensuring efficient resource utilization and maintaining service quality. But it seems like home grown solutions are often introducing hidden operational costs and complexities and current tools aren’t providing a holistic view of these interconnected systems. Effective capacity planning in distributed systems requires understanding how applications and limits interact in a living, breathing system, not just the limits of individual components. This turns out to be critical to providing a high quality of service as efficiently as possible. So, I'm curious: What do you wish your systems or tools could tell you that they currently don't? #StanzaSystems #CloudOptimization #EnterpriseIT #PlatformEngineering #SRE

40

10 Comments

The future of engineering design and coding is about here. Imagine simple text prompts that assist your software engineers in designing and coding complex systems, saving thousands of hours and months of work. Getting a smart code base and avoiding the dreaded Tech debt. I see Pledgecircle using AI engineer to assist with our 5 zero-to-one components system designs. It's a new world to build.

3

I was watching a video that talked about what software developers focus on at different stages of their careers, and one notable take was that "Distinguished Engineers" are focused on the *industry*, and not just their company. This is typically because they've engaged with communities outside of where they're working for many years. They say travel "broadens the mind", and learning from and sharing with developers in a wide range of situations tends to give people a much broader sense of software development. Not everything is Big Tech or Fintech or Medtech or Gametech. Not every product is a smartphone app or a website. Not every product has millions or billions of users. (Proportionally, very few do, in fact; so it's interesting how much we obsess over scale.) Not every code base is 100 million lines. Not every code base is 100,000 lines. Not every system has contemporary hardware to run on. Not every platform can accept updates easily (many embedded systems are ship-once). Not every bug or outage is merely an inconvenience (just ask an airline pilot!) Not every product is about profit. And so on, and so on. Learning about what other people, in other roles, in other organisations, in other industries, in other countries, do will tend to make you a much more well-rounded software professional. It will expand your horizons, as well as create opportunities for the wider developer community to have their horizons expanded from your experiences. In particular, there seems to be fairly wide agreement that a "Distinguished Engineer" has made a notable and lasting contribution to the field and the profession of software development. This seems to be encouraged in organisations who pay it forward; who are happy for their most experienced engineers to "share the love" outside of the walls of their business. When a dev, say, creates a testing framework or writes a book or organises a meet-up on their employer's dime, the employer recognises the long-term value of paying it forward. When employers insist developers engage outside of the business entirely in their own time, and entirely at their own expense, those people will usually end up distinguising some other company. And, of course, if that dev-all-the-way-to-the-top career track isn't on offer, then ditto :-)

40

Junior: "Look at this clever one-liner I wrote!" Mid-level: "I should probably add some comments here." Senior: "Let's refactor this for clarity." Lead: "How can we design this to prevent errors in the first place?" If we write code as cleverly as possible, we're setting ourselves up for debugging nightmares. It's not about writing less code, but about writing code that tells a clear story. Key principles I've learned: 1. Write for humans first, computers second 2. Optimize for readability, then performance 3. Treat comments as an essential feature, not an afterthought 4. Design systems that are hard to use incorrectly Today's clever hack is tomorrow's technical debt. Our job isn't just to solve problems, but to create solutions that stand the test of time and teamwork! #developer #simplicity #coding

204

62 Comments

Dev agencies, if you don’t want to be treated as a commodity, stop acting like one. - Learn the business context for engineering needs - Stop squeezing your clients every opportunity you get - Prioritize transparency, communication, and accountability In short, position yourself as a partner that uses tech to solve business problems. You really can’t complain about being seen as a commodity if you treat everything as a transaction.

1

1 Comment

This product was practically built for me. I’ve been waiting for something like it for years, long after I gave up writing on paper almost entirely. Heck, if it wasn’t for having kids, I probably could have gone the last the past decade with the challenge of not writing anything down on paper. Which makes it all the more frustrating at the price point it’s released. This isn’t targeted for grade school students, college students, or young professionals. It’s targeted at prosumers which share the same space as an iPad Air, and the market is already dominated by prosumers who want that product. For those who can’t afford the iPad, Amazon releases tablet computers in the $100 range. I know Remarkable is a much smaller company, and can’t compete on price with Amazon, or volume like Apple. But waiting so long for something I can’t justify the purchase price just hurts. At half the price it would have been a no brainer. It checks practically every box.

11

5 Comments

This is a really good post. I've often thought that async/await is a truly horrible paradigm to program in. Its hard to reason about the computation model, its hard to debug, its hard to trace, apparently they're all implemented differently and have differing lineages (TIL from this article), and it infects a codebase almost in toto. I also have a sneaking suspicion (although I've never been able to prove it) that programming this way doesn't lead to a speed up over doing more naive concurrency or parallelization techniques. Hopefully in the future this pattern will go away toward concurrency models that are much easier to reason about (like Channels in Go or Actors in Elixir). Even threads might be reasonable as the author suggests, but async/await is bad imo and I'm with him. https://lnkd.in/eu9PPFBV

7

2 Comments

on hiring an ea While companies like Athena and Wing are popular options, they come with challenges I didn't like: * Time zone differences * Cultural gaps * High initial costs ($3000+/month) Instead, leverage your network. Tell everyone you know that you're looking for an EA. You'll be surprised how many qualified candidates are already in your circle. Plus, working with someone who understands your culture and timezone is invaluable. Two crucial tips for success: Document everything. Create clear SOPs using tools like Notion or Loom. This makes onboarding smoother and sets clear expectations. Start small and scale up. Begin with a capped number of hours at a set rate. This lets you build trust and understand your needs. (Trust me - once you find someone great like my EA Maria, you'll wish you had more time with them!) Bottom line: Start with who you know, really just ask everyone for referrals first, document well, and scale gradually

6

The Unexpected Slack Hack You Need: 🦝 We’ve all been there: a Slack thread spirals out of control, and before you know it, people are lost in endless back-and-forth and you have a thread 70 replies long, or worse, multiple threads 🫠. The fix? A simple 🦝 emoji. Slack’s unique "raccoon" concept encourages users to shift off-topic or overly detailed conversations, here’s how it works: 1️⃣ 𝗥𝗲𝗰𝗼𝗴𝗻𝗶𝘇𝗲 𝘁𝗵𝗲 𝗦𝗽𝗶𝗿𝗮𝗹: When a thread goes from productive to chaotic or has more than a few back and forth replies, drop the 🦝 to signal it’s time to regroup. 2️⃣ 𝗠𝗼𝘃𝗲 𝘁𝗵𝗲 𝗖𝗼𝗻𝘃𝗲𝗿𝘀𝗮𝘁𝗶𝗼𝗻 𝗟𝗶𝘃𝗲: The raccoon tells everyone it’s time to move from typing to talking—whether it’s a quick Zoom call or a team huddle. Live conversations resolve issues faster. 3️⃣ 𝗙𝗼𝘀𝘁𝗲𝗿 𝗖𝗹𝗲𝗮𝗿, 𝗜𝗻𝘁𝗲𝗻𝘁𝗶𝗼𝗻𝗮𝗹 𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝗰𝗮𝘁𝗶𝗼𝗻: The raccoon keeps things respectful, but serves a real purpose—it gets the message across without adding tension. 4️⃣ 𝗘𝘀𝘁𝗮𝗯𝗹𝗶𝘀𝗵 𝗔 𝗡𝗼𝗿𝗺: Make it clear in your team’s culture that when the 🦝 appears, it’s time to shift gears and solve the issue more efficiently. How do you keep Slack chaos under control? Tell me in the comments. ⤵ ---- ♻️ Repost and share these tips for improving slack communication. ➕ Follow me (𝗔𝘀𝗵𝗹𝗲𝘆 𝗩𝗮𝗻𝗱𝗲𝗿𝗪𝗲𝗹) for more insights on productivity, leadership, and career growth.

23

8 Comments

One of the best ways to get a dev team stuck in analysis or design paralysis is to make them believe they're only getting one shot at it. Because then they'll pack for all contingencies.

49

7 Comments

Some unconnected thoughts on this “ghost developers” panic: Despite tech being a major economic driver for a couple of decades, MBA programs, and therefore the state of management thinking, are rooted in manufacturing. The mindless drive for efficiency in all kinds of businesses makes the most sense if you’re talking about factories and logistics. Not so much for knowledge work. Software is the only huge field where “R&D”, “production” and “services” are collapsed into one big undifferentiated mass. The output of product development is code shipped to production, and it needs to be continually maintained and updated. The closest thing software has to a manufacturing model is offshoring engineering to eg India or Eastern Europe, while keeping design and product/eng leadership in the US, but that creates ongoing problems because you can’t just hand off specs to India for manufacturing and move onto the next launch. Offshore teams need ongoing support because the customers need ongoing product support. Because engineers produce the actual shipping product, while they’re closer in spirit to fellow managers/leaders or an R&D team, the manufacturing mindset can only really make sense of engineering as the factory floor, and MBAs’ whole thing is looking for ways to extract extra pennies by optimizing manufacturing and distribution. They can’t actually do that with software, but they aren’t technical enough to know that, and it doesn’t stop them trying. So, “ghost developers” — which, of course, is just engineers writing good docs, being in meetings, talking to customers, supporting each other with code reviews or pairing — seems like gross inefficiency because it looks like a factory producing fewer LOCs than companies are paying for. Remember how, when Elon took over Twitter, we’d hear about him asking coders to _print out_ their latest contributions to the codebase, and if the pile was too short they got fired? Elon is a manufacturing guy, not a software guy. Even the “Stanford researchers” part is MBA culture gone wild — they have _no idea_ what’s involved in making software, and can’t even talk to their teams effectively, but they think their dumb mindset is “science” and now they have “research” telling them they could fire half their teams and be more productive. 🫠

1

Nothing spooks a developer quite like a good ol' fashioned legacy auth system. 🧟‍♂️ Legacy auth codebases... scary, slow, and covered in tech debt cobwebs. 🕸️ They’re the skeletons in the closet of so many dev teams, untouched for long stretches of time. 💀 Because let’s face it -- no one wants to be the one to open that crypt. ⚰️ But leaving that old auth code buried can come back to haunt you. 👻 New features can break because they don’t play nice with legacy auth code. 🧛 Security risks creep in through outdated practices and protocols. 🕷️ Scalability dies and onboarding new tenants becomes a horror story. 🦇 It might be time to replace that skeleton with a fresh, multi-tenant-friendly framework. 💪 🔒 Your dev team will thank you — no exorcisms required. ✝️ Thank you for putting up with my lame Halloween dad puns. 🎃 Now it's time to collect the "dad tax" on my children's candy buckets. 🍬 #TechDebt #LegacyCode #Authentication #MultiTenant #HappyHalloween #DadJokes #Wristband

4

2 Comments

When engineers say "no," it reveals flaws in your pitch or opportunity, helping refine your approach Here are a few common mistakes 👉 𝗖𝗼𝗻𝘁𝗮𝗰𝘁𝗶𝗻𝗴 𝗽𝗼𝘁𝗲𝗻𝘁𝗶𝗮𝗹 𝗰𝗮𝗻𝗱𝗶𝗱𝗮𝘁𝗲𝘀 - 1. Not including basics things like work location, comp range, and tech stack 2. Not highlighting what makes the role/company relevant for them 3. Targeting the wrong (or not enough) people 𝗙𝗶𝗿𝘀𝘁 𝗶𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄𝘀 - 4. Jumping right into technical questions before creating buy-in 5. Not pitching your company's vision 6. Not understanding why the candidate is interviewing and what they're looking for in their next role 𝗟𝗮𝘁𝗲𝗿 𝘀𝘁𝗮𝗴𝗲𝘀 - 7. Assuming candidates are interested, without understanding their decision framework 8. Not debriefing and addressing concerns after every interview 9. Extending offers without pre-closing Good recruitment involves a lot more than just finding top talent Have a great weekend!

8

1 Comment

I've personally worked on a lot of MVPs/v1 software products. Here is what I have learned the hard way: Ugly MVPs likely won't cut it anymore. Advice of a bygone era was to launch as quickly as possible, even if the product was crapy. In 2024, people expect a certain standard to the software they use. This doesn't mean MVPs are dead. It means they require craft. The goal for most MVPs is about learning as much as you can so you can iterate as fast as possible. If you launch with a lot of bugs, you risk getting bad signals. Did a user churn because the feature was bad or because it was buggy? Its hard for users to imagine a feature working bug free. The balance of moving fast and maintaining standards seems more like art than science. You want to be slightly embarrassed by how little you launched while while proud of the user experience.

12

2 Comments

Endor Labs published their 2024 Dependency Management report, and one of the stats that stood out to me (but was unsurprising) was this: 95% of version upgrades contain at least one breaking change. Maintainers don't want to break compatibility for their users. But they also need to keep their packages secure, and push their projects forward. Our approach has always been that dependency management is more about risk assessment, prioritization, and project management than it is about code changes.

4