Nicole Anderson

Get your code into production. One of my pet peeves is when a team develops new functionality QA for months before pushing to production…then are surprised when they try to push to production and (1) 4233 things break and (2) their business counterparts are underwhelmed with the result. My teams generally push to production every sprint - each user story must go into production Developing a muscle for regularly and frequently pushing changes as an IT/data organization forces you to: 1️⃣ Automate: common processes, security checks, quality 2️⃣ Containerize: everything should be reproducible including environments and packages 3️⃣ Decouple: if your deployment breaks it should not affect other teams/deployments 4️⃣ Simplify: deploy less at a time, also reducing risk

5

Pondering, or actually currently experiencing a problem of our dev team: We always somehow seem to miss celebrating accomplishments. Getting something done is just a new beginning. We rarely, if ever have those moments of "yay, we're done, the customer approved our delivery!"-moments, as we will be responsible of the outcome until the bitter end. It's hard to be content with yourself, when you're just prepping for something to go wrong. Made a notable production deployment today that replaces a previous, flawed implementation. My internal customer wanted to celebrate this, but what can I do but ask them to wait 2-4 weeks and see how it goes -- does it truly perform, what small mistakes must be fixed, etc. And in 2-4 weeks time I will have, and must have, something entirely different in my mind. Is this a problem common with all in-house software development teams? Or just a pessimistic approach of a Finn that ruins everything? Eeyoreism?

23

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

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

If anyone tried to e-file their taxes with H&R Block desktop software, over 24 hours (Sunday, April 14th until midday April 15th), they would have failed. https://lnkd.in/gycJmDDN Let me break this down for you - this is a CLASSIC n-phase commit issue. I would NOT be surprised if they are using threads to meet this need and of course, they are failing spectacularly! Why? Because as much as I love threads, I have been using threads since 1994 or earlier, large-scale, heterogeneous systems architecture is never to be built with threads! Threads mean you hope you can control the spanning and the response times. Otherwise, the countless waiting threads chew up cycles, timing, and the overall machines, until you have system starvation. The proper way to manage unbounded interactions is to use non-blocking (event-based) architectures. This allows the backend to manage the many disparate systems it needs to interact with and ensure they are completed and the customer knows the final outcome. I stress, the last point - you can have the best backend system out there but unless the customer interaction model is equal to the backend model, the customer will not know what happened. If the backend is trying to do many things in an async manner but uses a sync user interaction model then the customer does not know what happened. The customer may be trying to e-file their taxes, which is at least two steps, charge the card and file the taxes with at least one government system, maybe more. If that interaction on the backend is done async, and then it fails, the customer's interaction model will also fail, and now the customer is left in a place where they do not know what happened! Many customers, in this case with HRBlock, actually had their e-file work, but they never knew it! Eventually, the Federal Government emailed them saying that the taxes were filed. Which is a horrible user interaction. The main point here is that all complex user-facing interactions on the backend need to have a user model where the customer knows what happened and if they can try again! Failure is NOT an IF it is just a WHEN. One MUST build their architecture embracing failure. In the end, persistent orchestration, using things like Airflow of Amazon Steps, along with idempotency is the only way to ensure that the customer will get the outcome they desire. System failures is expected, systems not giving the customer a final understanding of where they stand on such important transactions is a failure. If the user experience is clear in stating that the user's request is being handled and then the backend fails, but the user experience is not tied - directly - to that backend, then that one level of abstraction allows the experience to do retries and poll for the state of the backend's final outcome. Best wishes to all for success and much better outcomes than my annoyances this week!

17

2 Comments

I was paying my property taxes today, and I'd like to give a shout-out (again) to the LA County property tax website: this could be a model site, in an educational sense, for how to make every single idiotic design blunder possible in a web app, both from a usability and security perspective. It seriously takes some dedication to doing every single thing wrong to be this terrible. Overlooking the awful and very dated UI, some specific bullet point examples of offensively terrible design decisions: - You need 3+ separate click-through agreements to pay your taxes (WTF; nobody reads these ever, why have more than one worthless interstitial?). - The checking routing information you enter is both masked (so you cannot see mistakes), and you need to type in twice, AND they try to prevent copy/paste. WTF are you thinking? Does anyone have a brain there? This is performative security idiocy writ large. - You have to enter additional PII which is totally unnecessary, AND they already have (eg: address info, which they used to send the bill). - The site login requires three "security questions" (aka alternative passwords), all based on public information. - [bonus] They have a way to create a "profile", so you don't have to enter information every time, except it doesn't actually let you do anything from the profile, so it DOESN'T DO ANYTHING! This is, imho, the single most poorly designed web app I have been forced to interact with in at least the last decade, and that's impressively bad. You are a shining example of monumental government incompetence without consequence.

9

9 Comments

Venturing into an unfamiliar industry can be daunting, but it's also a powerful opportunity for growth. When I started Tradeline Works, I had no prior credit experience. But stepping out of my comfort zone taught me that true expertise isn't about what you know, but how you approach learning and problem-solving. The same applies in software development. It's about being open, adaptable, and willing to dive deep into new challenges. Embrace the unknown. Be fearless in your pursuit of new knowledge. Your ability to thrive in unfamiliar territory is what sets you apart and drives innovation. What's one career move you've made that felt daunting? #SoftwareEngineering #CareerDevelopment #GrowthMindset

12

When building software, what is Product Definition? I've found that there's a large focus on prioritization, planning, and process (on the product management side) and design and development (on the software engineering side). But the product requirements get lost in project management software or locked away in a code base. How can we capture and preserve those requirements? Maybe the first step is to define Product Definition. Here's what I've identified so far: 1. Actors - The people using the system 2. Actions - The business processes, workflows, etc. 3. Resources - The things operated on (objects, files, etc.) 4. Rules - The policies that govern the system (conditions, access controls, etc.) Anything you'd add to this list? #productmanagement #productdefinition #productrequirements #technicalrequirements #softwareengineering

13

7 Comments

Ticket velocity isn't the *only* measure of an engineering team's effectiveness. At a high level, the best engineering organizations can predictably deliver against the priorities set forth by the business. That involves proper monitoring (through metrics) and coaching by effective managers. Here's a few non-velocity metrics I use to measure my organization: - Tenure of the team. - Platform uptime. - Number of critical issues in the last 8wks. - Automated code coverage percentages. - *Employee* vs customer detected bugs. - Number of requirements missed during project planning. Read more about my leadership style here: https://lnkd.in/geP2m7DJ #metrics #engineeringeffectiveness #team #leadership #software #tech #startup #management #dora #space #agile #projectmanagement #podcast

2

I'm in the home stretch on a pretty big project right now, and it's so energizing. We're at the polishing stage before release, and it just feels good to do the small, tedious cleanup for a little while. It's a break from the heavy lifting of design and experimentation. The learning curve has smoothed out a bit, and we can practice. There's much value in practice. Too often, engineers chase the new and exciting because of the thrill of discovery. However, there's much learning left to be done during practical application. You can validate your initial assumptions, challenge your choices, and develop and reinforce good habits while winnowing away the bad. Maintenance mode isn't just about sustaining. Take the opportunity to continue learning, push your boundaries, and challenge yourself to attain true mastery.

28

Those of you out there using Claude, make sure to enable the new artifacts feature (still in preview). It's super useful, it can even under certain circumstances run code it generates so you can preview the results. Try it!

19

4 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

Following the Pareto principle 80% of the outcome can be achieved by applying 20% of the effort. And if a new product or feature is being built typically the remaining >=20% of the outcome (usually more than that) will not be needed at all or something altogether different will be required as more is gradually discovered after the first release. Defining the scope wisely and iteratively improving on the first version is key to improved speed, quality and reduced costs. Also feedback will be received much faster and learning will happen earlier. In comparison in the classical waterfall model scope is fixed, delivery is late, costs are exceeded, quality suffers under the time pressure to follow the plan and feedback after the release is either received too late or ignored altogether. The result is wasted effort and less value delivered. It comes down to working smart, delivering often, producing value and learning fast from the users vs following the plan, being late, overrunning budget, ignoring feedback and producing hard to use or useless software #extremeprogramming #agile #productmanagement #softwaredevelopment #paretoprinciple #waterfall

1

I can just hear the Flutter team panicking over this one. A good way to transition to KMP if you haven't (plus native stacks). Risk is a real thing when choosing a tech stack -- Flutter has always placed itself at an extraordinarily high risk point. I can't state this enough, do not put your showcase projects in a position of high risk. Business wise and strategically, this is foolish and only reveals inexperience and poor leadership. https://lnkd.in/gZWQ_RE5 Some key highlights: "TLDR: We're still keeping it ticking, but we're being more up-front that CocoaPods is in maintenance mode." "E.g. I maintain Unity, React Native, Flutter etc. A lot of these projects will (and should) be migrating to Swift Package Manager with time. As specified above, we are not breaking anything but bugs you may raise are unlikely to get fixed."

5

Estimating Effort is typically flawed. I've been recently intrigued by talk on LinkedIn about how Story Points in Agile development are terrible and should be avoided at all costs. I don't generally get into that sort of debate, because usually it ends up being an argument about one person's lived experience versus another. Instead I thought I'd contribute to the conversation with my own experience of using Story Points as an antidote to estimating by effort which is often (always?) flawed. First off, on the subject of estimating by effort, this is what I think... In order to estimate by effort on any reasonably sized backlog, you need to know three things: 1. What work you need to do. 2. Who is going to do it. 3. When it is going to get done. You need to know the first thing so you can identify tasks and assign an estimate of effort and/or time to each item. You need to know the second thing because and experienced developer might take one day to do something that an early career developer might take 3 days to do. And you need to know the third thing, because in my experience, most development teams accelerate as they go through the work. Without knowing those three things, any estimate you come up with is just a guess, and you will have to rely heavily on contingency, which makes your estimate a work of fiction. I've been working in software for a loooong time, and estimating effort hasn't often been successful. How often do we know those three things at the start of a significant body of work? Contrast that to the way I've preferred to work for quite a while, using relative complexity estimating, story points and a measured velocity. Without knowing every task you need to do, it is usually possible to find the least complicated thing you need to do (and give it 1 point), the most complicated thing (and give it, say, 8 points) and then assess everything in between for complexity relative to the other things you've already expressed a view on. You end up with a total points balance, and then if you know when you want to deliver it all by, you know how fast you need to go in terms of a points delivery per iteration. What it has historically allowed me to do is use language like "In order to hit the aspirational date of x, we need to maintain an average delivery of y / iteration". And you knew very quickly if you're going fast enough. It unlocks conversations early about adding capacity or modifying scope. I know loads of people will come up with reasons why this is flawed or hasn't worked for them, but I'm putting it out there as my experience. In 31 years of software development I can say with confidence that those bodies of work delivered by estimating effort have been less successful than those using points and relative complexity. I'm always open to learning, though, so I'd love to hear in the comments about alternative ways I could consider that improve on that approach.

7

8 Comments

Ever have a problem migrating your production sized statistics to your development systems? Why would you want to? How would you do it? Come listen to Todd Mollenhauer discuss this lively topic! Register today! https://lnkd.in/gD8gTW5p

19

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/)

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

5