Rob Cecil

4 Things You Should Put in Your Daily Dev Log To harvest meaningful patterns from your dev log, you’ll need to capture the same things daily. I’ve been engineering software for 25 years, and I’ll share what I’ve routinely kept in mine. Your context is different, so your list will be also. Just make sure you capture the same things daily. Use this list as a skeleton to start from. It’s easier when you aren’t starting from a blank page! Pull Requests I keep track of every PR I submit, approve, or merge. Almost any work product I deliver or review flows through Git. My lists of PRs serve as a personal task-level kanban board of work in progress that I am connected to. These help me easily reconstruct a story of what I’ve done throughout the week. Personal Interactions I make note of every personal interaction I have, scheduled or otherwise. In addition to these notes, I keep a page for each person, and I link to that page from my daily notes. As I note patterns of interaction with a person, I’ll describe those patterns on their page. Over time I build a library of every person I’ve collaborated with and what we worked on together. Project Actions I keep a running narrative of the things I’m working on. I keep a section for each thing I’m working on. These might be at the product or story level - it just depends. Each time I hit a stopping point or interruption, I make a note of what I’ve been doing and what I plan to do next. Guess what I use to inform my daily standup updates? Perplexing Puzzles I make a note of everything that surprises me. These could be strange program behaviors, blockers, production issues - anything unexpected. As I review these periodically, I ask myself how I can use what I’ve learned to improve my mental models. Hopefully this list helps you get past the starting line. Do this faithfully for several months and see where it takes you!

8

8 Comments

Donald Raab and I recently had a conversation about his upcoming book Eclipse Collections, Categorically, his 40 years of programming experience, and the sheer joy he still gets from writing code. Whether you’re looking to up your Java collections game, learn career or life lessons from an industry veteran, or just want to be entertained, tune in to my latest podcast episode (link to episode in the comments)

105

3 Comments

This is a great blog entry on the "devaluation of frontend" development. https://lnkd.in/gDuGeh7n You should read it. A few passages that jumped out at me: "We often aren’t included at the beginning stages, where we could easily identify costly accessibility, performance, and user experience mistakes; we’re brought in at the end, when things have already been built and it’s too late to change anything significantly." - THIS - I had a job for awhile where I was treated as a fixer/styler in spite of 5+ years at that point as a professional developer working in both backend and frontend languages. It was like getting very skilled at UI work made folks skeptical of all of my backend and regular programming skills. That was in spite of having a math degree and starting my software engineering career as a python developer. Meanwhile, you wouldn't believe the skepticism that we encounter when trying to tell folks that there is a "right" way to build the frontend so that you don't have to go back and fix accessibility problems or cross device issues. Because frontend skills are so devalued, it is very common to just expect a backend engineer to do them regardless of whether they have ANY skill in that area. I've seen it happen many, many times that a person with sometimes LESS than entry level skills on the frontend are just assigned to build new frontend features or make a major UI update. I mean it is literally common for someone who could NOT get hired as a frontend developer to be assigned to build a major new frontend/UI update. To use the building analogy, it's like you suddenly decided your plumber installing your sinks and tubs should be able to handle the installation of windows, doors, shingles, trim and paint. And this bit (https://lnkd.in/gMdmebAj): "Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room." Yes, this. And guess what? Bad HTML and CSS can eat up your time and resources just as surely as any other part of the codebase. But now that you are putting someone on it who doesn't have those skills, like a very expensive backend software engineer with more than a decade of experience, you may be taking many times longer to find and resolve the problem than if you had put someone on it who works with it every day, or that was actually an expert. I mean should you put someone on that UI bug who cost $60/hour and can fix it in 10 minutes or someone that costs $100/hour and can fix it in 6 hours to a week? I am NOT joking about those times. Expertise and skills in one area of the stack, does not magically jump over to others.

4

Introducing the all new logo for The Code Gardener (https://lnkd.in/gJ_azQak)! Obviously, we need stickers! But, what shape? I'm leaning toward square. My partner in crime, Fito von Zastrow, is leaning toward die cut. What would you put on your laptop? #graphicdesign #blogging #ruby #rails #softwaredesign

34

7 Comments

There’s something for everyone in web development in here:

8

1 Comment

I'll be speaking at GOTO Chicago next Tuesday, 2024-10-24, on JVM performance techniques in Jepsen: https://lnkd.in/dZWviHim Jepsen is a Clojure library for testing distributed systems correctness. We'll talk about how Jepsen records and analyzes histories of up to a billion operations with the help of a new file format, faster lazy and persistent data structures, bit-packing, memory-adaptive caching, associative folds, and thread-safe transactional executors. Come learn about some of the lesser-known corners of the JVM and how to write faster, more efficient programs in any language. This talk will benefit intermediate to advanced engineers interested in performance optimization, parallelism, and medium-sized datasets, while also offering insights valuable to both beginners and senior engineers.

23

New post up on the blog. In this one, I reminisce about PHP and warn against abusing lambdas. https://lnkd.in/gDGuQFsE

5

Wow. There is a lot to love about this introduction to coupling and cohesion. It has the most cohesive explanation of cohesion I’ve ever read, and I think I finally understand how to evaluate design cohesion, which has been elusive to understand. https://lnkd.in/gEchqnEJ Whenever I mention coupling, however, I also feel the need to point to connascence, which I learned about from Jim Weirich and still influences my thinking more than a decade after I first understood it. (https://connascence.io/)

For folks who've used copilot or other genAI tools a lot, I'm curious how good the unit test generation ends up being long term. I'd be concerned that you'd end up with a lot of test suites that verify exactly what you implemented, which are not going to be as useful as TDD cases that are more focused on the intended behavior rather than the code you wrote (which might have latent bugs to begin with)

18

1 Comment

I've worked on a number of libraries in my career, some open source and some not. One thing I've learned is that it's hard to design good library interfaces! This was stuck in my drafts for a bit and was on the verge of getting too long, so I edited it down and published it. Here's a quick read on the lessons I've learned along the way that might be helpful to folks. #softwareengineering #programming #softwaredesign https://lnkd.in/gFVpPA8F

11

Software engineering is not the same thing as just coding, why don't people understand that?? Most of software engineering is actually thinking about and understanding the ecosystem/requirements. Once you understand that, writing the actual code is actually usually quite easy.. easy enough that it can be outsourced to AI maybe.

19

3 Comments

24 years ago, Joel Spolsky's "Things You Should Never Do, Part I" became gospel in software development - never rewrite your code from scratch. But AI is about to rewrite those rules. The traditional risks of rewrites were about _time_ - every month spent rewriting was a month not improving your product. But when AI can rewrite code in hours instead of months and produce right-sized, lean, secure solutions, the calculus changes dramatically. Soon, the question won't be "Should we rewrite?" but "Why haven't we rewritten yet?" This shift promises to transform how we handle technical debt, legacy systems, and platform modernization. You can read more here: https://lnkd.in/e-Bwbife

9

Appreciate seeing that App Store review time has roughly halved since the summer (down to about 4hrs compared to 9hrs). I can't help but wonder why starting a review for Testflight external beta is still at the 8hr mark (though I certainly understand that those should be lower priority compared to production builds). I +1'd the Google Play IN_REVIEW status issue and recommend others do the same! On the green goblin [Android] side of things, I've personally experienced a lot of variance lately, resulting in some unexpectedly [days long] reviews. I also see that Google recommends waiting for production reviews while alpha reviews are in-progress, citing longer review times. My experience has been the opposite, where the synchronous reviews results in a MUCH longer review cycle. The numbers point to improvement, but there's still further progress to be made, both for timing and consistency of policy enforcement.

9

1 Comment

Some takeaways for a Jeff Hinton interview with timeless insights. My POV as an app builder is that models are now being improved for better UX (faster response/multi-modal) and reasoning capability and cost continues to improve. The technology headroom remains strong, and the integration of LLM into all software experience will continue and expansion of the reach (invasion) of software + intelligence will also continue. - Next word prediction is not merely parroting of training data. To do next word prediction well, LLM needs and already exhibits strong reasoning behavior. This would continue to scale / improve with more data / training. - LLM is a compression of human knowledge. The compression mechanism is identifying similar concepts across domains and reduces duplications among them. This can also be a source of "creativity" as LLM "sees" correlations of seemingly unrelated ideas through this compression. LLM can be more creative as it sees similiarity / correlations across all domains beyond (human) convetional wisdom. - LLM can exceed the quality of its training data. Jeff gave an example of an experiment where a model trained on 50% intentionally incorrectly labeled data, can still perform at 90+% accuracy after training. - Multi-modal models can improve the overall world understanding and lead to better overall reasoning. It does not even need to generate multi-modal output. - Not ML specific, but an interesting life insights. Bad intuition comes from believing (or wanting to believe) everything you are told. It diminishes the ability to make a clear choice that would lead to differentiated success (or failure).

4

📚 I can't believe I didn't read "The Pragmatic Programmer" sooner. Published 20 years ago, it made a significant impact on the software industry and remains as relevant today as it was then. No matter how quickly the tech industry advances—think AI and new trends—the core principles of coding endure. Dave Thomas and Andy Hunt's insights in this book are timeless and applicable not only to software development but also to Computational Design. If you're curious, just the first two chapters offer valuable lessons. The authors' approach is profound and offers practical guidance that stands the test of time. One of the assertions from the book that deeply resonated with me is: "𝗛𝗮𝘃𝗶𝗻𝗴 𝘁𝗵𝗲 𝗯𝗲𝘀𝘁 𝗶𝗱𝗲𝗮𝘀, 𝘁𝗵𝗲 𝗳𝗶𝗻𝗲𝘀𝘁 𝗰𝗼𝗱𝗲, 𝗼𝗿 𝘁𝗵𝗲 𝗺𝗼𝘀𝘁 𝗽𝗿𝗮𝗴𝗺𝗮𝘁𝗶𝗰 𝘁𝗵𝗶𝗻𝗸𝗶𝗻𝗴 𝗶𝘀 𝘂𝗹𝘁𝗶𝗺𝗮𝘁𝗲𝗹𝘆 𝘀𝘁𝗲𝗿𝗶𝗹𝗲 𝘂𝗻𝗹𝗲𝘀𝘀 𝘆𝗼𝘂 𝗰𝗮𝗻 𝗰𝗼𝗺𝗺𝘂𝗻𝗶𝗰𝗮𝘁𝗲 𝘄𝗶𝘁𝗵 𝗼𝘁𝗵𝗲𝗿 𝗽𝗲𝗼𝗽𝗹𝗲." 𝘋𝘢𝘷𝘦 𝘛𝘩𝘰𝘮𝘢𝘴 𝘢𝘯𝘥 𝘈𝘯𝘥𝘺 𝘏𝘶𝘯𝘵 https://lnkd.in/g7vrfY-C #BookRecommendation #SoftwareDevelopment #PragmaticProgrammer #ComputationalDesign

24

4 Comments

I’m intrigued by the internals of JAX’s transformations, such as jax.grad and jax.jit. JAX’s documentation briefly introduces the concept of a **Tracer**—a stand-in for JAX Arrays that records execution progress and captures information about intermediate results. Here’s a simple code snippet that reveals some intriguing properties of Tracers: 1. Each transformation relies on a specific type of tracer. For instance, jax.jit uses DynamicJaxprTrace, while jax.grad utilizes JVPTrace. 2. When we compose transformations, such as jax.jit(jax.grad(f)), the traces are composed—meaning the primals in JVPTrace are traced with DynamicJaxprTrace.

52

Having a ton of fun writing an ORM for V2 of Case Kit. Typescript has such an incredible type system. I have autocompletion for column names, the ability to include relations, relations of relations, etc etc etc... all returning properly typed data (no classes in sight). It's been really satisfying seeing it coming together, and it's been great getting my hands dirty with some (relatively) complex generics. And to head off the obvious question… why aren’t I just using Prisma? Well there’s a couple of things I’m doing differently that I think are marginally better: there’s no code generation involved here, it’s just types (inspired by Drizzle); there’s no Rust binary you need to deploy, and it hews much closer to Postgres behaviour and syntax (the aim here is not to abstract away which database you’re using). But the real blocker to me using Prisma was that its extensions don’t support modifying queries of nested relations - a hard requirement for me due to the way I have multitenancy and soft deletes set up. It’s not shown in the video but the Case Kit ORM lets you write simple middleware that will be applied to every level of a nested query. Perfect for setting timestamps or adding clauses on tenant id or things like that.

21

Whew, fellow engineering managers, do we need to talk? We had more yeses to these three questions than either front-line engineers OR execs: 📈 I do not feel the potential for advancement in my current role 🚀 Leadership at my company is out of the loop when it comes to engineering challenges 💥 I do not feel secure in my current role. Pair that with the 69% of EMs who’ve experienced burnout in the past year and it’s enough to make even the best of us look at the engineer/manager pendulum with renewed interest. For me, the saving grace is the big improvements we as an engineering industry have made on informing and driving the business strategy over the decades I’ve been in tech, and wanting to stay in the room where it happens. Check out the 2024 State of Engineering Management to think about where you and your team falls on the trends we're all experiencing firsthand. (And for funsies, you won’t believe which group thinks AI is a gimmick. ✨)

12