Caitlin Buckhaults

i think we frame hiring "juniors" weird in order to avoid talking about calcification. doing anything, literally anything, for a long time, makes you better at doing the thing, but worse at doing adjacent things you do not also practice (ex. working effectively in a strong test culture does not help one optimize for hip-firing kubectl commands, and *does* explicitly optimize for taking one's time and thinking heavily). your "seniors" and "juniors" provide similar value adds in terms of where they say "what the fuck?" seniors only say "what the fuck?" when they encounter bad behavior *that they have not already calcified in themselves*. your seniors all have a few absolutely awful habits that make your product worse, waiting for a convincing junior to say "what the fuck?" at the ideal moment to *fix* them. if you don't find that convincing junior, they will propagate that calcified misbehavior throughout your org and sink your shit. you also probably don't know what the problem is, because you share the calcification. and this is all normal and good, because if you're arrogant enough to think that you deserve a team of only seniors, you deserve exactly what that gets you.

11

1 Comment

Another thing I do is track my time, religiously. Every single bit of "work" time I spend is tracked by client (which is sometimes my own company), project, and task. This makes it easy for me to see what I was doing, when, who it was for, and how long it actually took. I can also generate reports to see how much time I spent on certain types of tasks, including mundane things like "Processing" (which includes email, Slack, etc.)

5

I've been thinking a lot lately about ways of structuring IaC code, specifically - should this code be separate from application's code, or they can (should) be kept close to each other. When writing backend code, my rule of thumb about managing transactions (and other resources, like connections) is that a method or class cannot interfere with its (transaction's) state if that transaction has been started somewhere outside of that code. In simple words, only a piece of code that started a transaction should make a decision to commit or roll it back. Looks like this model can be applied to codifying infrastructure as well. If an application owns the lifecycle of an infrastructure resource, it is okay to put them in one source code repository. Short unpolished writeup on this topic: https://lnkd.in/emzDC9Nn

2

Looking back at this year's KubeCon NA, this is the talk I found most thought-provoking. Enabling developers to run CI "pipelines" locally is important work in its own right. This talk goes a step further, and proposes that all builds prior to merge (even your PR builds) could happen locally. If your developer workstations are powerful enough, you'll ease the burden on your CI infrastructure by doing so. https://lnkd.in/eG55b4b4

3

Good management of technical debt empowers you and your team to provide greater value to your customers, and to do so faster. Ultimately, your customers will feel everything that you invest time in. Technical investments are worth it!

11

1 Comment

Recently I was reading about the VW data disclosure, and I was thinking: could an LLM spot this? So I built a small prototype using PDL script, and the results are pretty good to be honest! More detailed information here: https://lnkd.in/dqJSMPkU

5

Anyone have experience transitioning from low code/no code development positions to code heavy ones? I recently was speaking to a colleague who was wanting to get into a more engineering focused role, but only had professional experience operating internal no code/low code software solutions. He asked what he could do to transition to a more programming heavy role and whether his experience wouldn’t count and he’d have to take a pay cut. Anyone have experience making the transition? What was it like and what advice would you give? #LowCodeToHighCode #Advice

5

8 Comments

The latest Qwen2.5 Coder models outperform Sonnet and 4o on some benchmarks. Try it on Wingman today!

4

If you think that keeping track of tools in software development is daunting, you're focusing on the wrong thing. Technologies keep changing, but requirements rarely do. Take version control, for example: we had SCCS in the 1970s, RCS in the '80s, SVN in the early 2000s, and Git and Mercurial after 2005. Yet the core requirement for version control remains the same. The same goes for CI/CD pipelines: CruiseControl in the early 2000s, Jenkins in 2005, then Travis and CircleCI. The need for automation hasn't changed. Infrastructure as code? We had CFEngine in the '90s, then Puppet in the mid-2000s, followed by Chef, Ansible, and now Terraform and CloudFormation. But the fundamental requirement is still the same. So, don't be scared. Focus on understanding the requirements and needs. The rest is just finding the tool that works best for you and reading the documentation.

42

I’ve been having a few discussions with TDD aficionados.  We talked about whether they use TDD all the time. It appears that there are instances, particularly in graphical applications, where the test/evaluation is done post coding.  For example, rather than write an automated  test for an object’s depiction, they code and see whether the object appears correct. It was suggested that there may be other times when TDD might be less applicable.  For example, in a pool program, one needs to calculate the result of two balls colliding.  The inputs are the balls’ positions and velocities, and the outputs are the balls’ new velocities. (One could add angular velocity to make it a little harder.) So, I offer this as an interesting problem. Can this function be developed by TDD?  If so, what are the steps? Daniel Moka Al Shalloway Rob Myers Justin Beall Tim Ottinger John Crickett

6

38 Comments

Along with general engineering and architecture efforts, I've spent the past 12 years helping orgs move from a dev-ops team to a dev-ops mentality. One thing I've refined and learned from+with others along the way is the concept of a "Dev Ops Contract". It's a concept so simple, it's often overlooked, but some powerful benefits are: - Clear understanding of what software requires to be operational - Reduced complexity in runner configs (github actions, AWS codebuild, etc...) - Developer autonomy - Parity with local and remote task execution Read about additional gains here: https://lnkd.in/gMNbtcP3 Is anyone else out there decoupling their CICD from their services in a similar way?

9

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

Woah there, "hiring juniors is about making your entire team better" is exactly the kind of unhelpful, oversimplified headline that needs an A4 sheet of caveats adding. Juniors are a massive investment and the suggestion that simply hiring them will make the team stronger is not right at all. Processes that support the career development of more junior engineers aren't accidental byproducts, they're deliberate. Senior engineers need to be provided the time, headspace, training and support to coach, mentor and develop their more junior colleagues. You know what doesn't work? Hiring juniors into overstretched/under-resourced teams where the seniors are overcommitted and under pressure to meet aggressive deadlines. And I've seen this more times than I care to mention. In the scenario where you've got small teams that are under pressure, and the existing engineers don't have time or headspace to coach someone junior, you are *always* better hiring another senior. Someone who reaches autonomy faster will always be better in that situation. If you hire a junior into that team you won't get better code reviews, more innovation or a richer culture of learning. You'll end up with an under-developed junior who struggles to progress their career, and some seniors who feel like they're doing the junior a disservice by being unable to support them properly. It's horrible. And I've been there. Were we all juniors once? Yep. Should *every* team hire juniors? Absolutely not.

4

‘In this episode of “The Engineering Room” Dave Farley chats with renowned author, speaker and expert software developer Kevlin Henney.’ https://lnkd.in/gsenvBMQ ‘In their wide-ranging discussion they talk about: • Why Kevlin Henney is famous for big public software failures! • Software Engineering, mathematics and the interesting gap between formal programming and sloppy humans. • Architecture, empiricism and three ideas for design. • Coping with incomplete knowledge and making stuff that works in the real world. • Confidence, certainty and loose-coupling. • Learning from actual failure, not just simulation. • Programming is deceptively easy to start, and gets complicated really quickly: Low Code is no exception.’ Continuous Delivery Ltd Bernard McCarty #ContinuousDelivery

21

If you're the kind of person who's excited about all the recent S3 feature announcements (bucket policy unlocks via temporary root sessions, up to millions of buckets per account, pagination and region filtering for ListBuckets, conditional writes, ListCallerAccessGrants API) and you're attending re:Invent, then you should come to our storage track session, STG306 Advanced security patterns on Amazon S3. Learn how to use all the exciting new stuff securely in the most interactive format available at re:Invent!

94

2 Comments

I once asked a lead engineer on Angular: Which is better: Angular or React? His response: "Both require good engineering to be effective." So, my developer friends, consider this a reminder that "frameworks" like Diátaxis are fine, but they still require good engineering--such as UX, information architecture, style, maintenance processes, and so on--to create great documentation experiences for your customers. Alas, the framework alone isn't enough.

35

7 Comments

I have found a pragmatic approach to TDD works good in practice. Might call it TSD (Test Supported Development). It is a bit like Bidirectional Path Tracing - tracing either from the source or the sensor easily undersamples difficult parts of path space - combining both does much better. I have experienced the same in software development: writing the product and writing the tests both inform important architectural decisions. I try to do both in an interleaved, incremental process. And while tests are not the product themselves, they are 'requirements as code' and are a great tool to find gaps in the requirements early. They also help to keep the architecture clean, the code maintainable and changeable and make QA less tedious... But code coverage as a metric is almost useless - you can't cover every (mis)use, case of bad data and attack vector ...

4

Check out this article about URL shortening: #womenwhocode #softwareengineer #softwaredeveloper https://lnkd.in/ej_3zTx5

1