🔨 Jon Hartmann

DIY Van Build vs Microservices vs Chief Slowdown Officer Building a DIY van is a lot like building a house at first. But one day, once you're on the road, you realize it’s nearly impossible to hire a contractor to fix mistakes on a weekend in the middle of nowhere. The choices you make during the build can have significant consequences, especially when dealing with features involving fuel, water, electrical systems, and safety. In van builds, as in software development, breaking down your needs into smaller, manageable decisions (similar to microservices) allows for simplicity and flexibility. In the video below, I mounted the diesel heater in the engine bay. The decision not to permanently install the diesel heater inside the van and drill holes through the floor had several benefits: diesel fumes out of the van; easy replacement and cleaning; improved safety without running fuel lines inside the van. The onboard air compressor is mounted next to the diesel heater but can be removed for use elsewhere, adding to its versatility. This version of the van is a prototype (1/N). The common belief is that during prototyping or creating a proof of concept (POC), you need to make quick decisions to Get Stuff Done (GSD). While the value of a Minimum Viable Product (MVP) is clear, it's not always the best approach. The alternative? Maximum Viable Options (MVO). MVO doesn’t mean getting bogged down in analysis paralysis or moving too slowly—it means being deliberate. Think of yourself as the Chief Slowdown Officer (https://lnkd.in/gN42uwfN, @ 1 min mark). One of the hardest aspects of a van build is the electrical system. By taking time and delaying this part of the build as long as possible, I was able to visualize the wiring diagram repeatedly and virtually test the wiring and electrical flow. When I finally started building, it went so quickly over a single weekend that I thought I had made a mistake. But, channeling the Chief Slowdown Officer mindset, I didn’t turn the system on immediately. Instead, it went through a review and certification process. This careful, deliberate approach made supporting the system easy. Being a Chief Slowdown Officer is similar to how athletes—like pro basketball players or golfers—slow down and visualize the shot before committing to it. This is a powerful technique for architects and engineers. If you can slow down and visualize the architecture and dependency graph of everything you build, then OpenAI has no chance. At least, not yet. More on that later. Van facts: 400W solar panels, 5kWh battery bank, bi-directional charging with the van’s battery/alternator, 20-gallon fresh water tank, 16-gallon remotely dischargeable grey water tank, a power-assisted bed lift, 8,000 BTU air conditioner, onboard air compressor, heated floor, walk through shower, bio waste disposal...

5

1 Comment

🚀 Quick shoutout to The Browser Company for Arc! 🚀 I've been using Arc lately, and I’ve got to say—it’s seriously impressive. The design is super sleek, and navigating around feels so natural. They’ve really nailed the balance between functionality and simplicity. One thing I love is how organized everything is—no more tab chaos! The customizable sidebar is a nice touch, too. One thing that’s missing, though, is Arc for Android. Once they launch that, I think it’ll really complete the user ecosystem and make Arc the go-to browser on all my devices. If you’re looking for a better browsing experience, definitely check out Arc. I think you’ll love it as much as I do! https://arc.net/ #TechInnovation #ArcBrowser #Productivity

5

Jr. Devs, You need to start thinking outside the box when it comes to your career. I was talking to a friend of mine yesterday and they were telling me about a small business their children (12 and under) had started. I won’t reveal what it is to protect their small advantage. :) But basically, it's providing a simple service that takes very little time for very little cost. It's offering a convenience. Anyway, as he was telling me about it, it was so simple, so obvious, but something I would have never thought of on my own. I’m not really an idea person. I need something to start with, a clear problem to solve. I often need a pre-defined path to follow. Many Jr. Devs need to be less like me, trying to follow the pre-defined path, and more like my friend, looking for things other people might be missing, opportunities no one may notice. Think about ways you could implement what you are learning to help individuals, small businesses, local governments… virtually anyone; to fix a problem, meet a need, or simply make someone’s life easier in areas they may not have thought of themselves. The traditional route into development is clogged right now, so perhaps it’s time to look around and see opportunities from a different perspective. Find a non-traditional route to begin using your skills in a career that might look a little different from everyone else. Who knows, you just might stumble on the next Uber or Airbnb or maybe you just build a great list of clients who need simple work from a trustworthy developer. Take a fresh look at the problem and find a creative solution. #juniordeveloper #mentoring

14

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

We had to make a quick architectural change when we got a new requirement out of the blue for our project. Here's a run down: We had an hourly-job scheduled through AWS EventBridge. Essentially, a Lambda function is invoked every hour. We set up a step function so that we can pass a list of objects and have it mapped across multiple invocations. Now the new requirement was to allow users to update this payload/list. My solution (which is currently in prod), was to create a new table in our database (RDS/Postgres) and store the payload items there. The step function was then altered to invoke another Lambda to query the table and parse the items into a json array > Said array is then mapped and used to invoke the main lambda function. Could this be improved? Scaling is not an issue here as the payload array will never have more than 20-25 items. If you've worked with these services before, do suggest if there's a better way.

12

The "80:20 Rule" is probably one of the most quoted heuristics in software engineering (more so even than DRY), because it can be applied to nearly any situation, even paradoxically. Yes, "80% of your users use 20% of your features" is a good reminder that general functions are most often used and edge case implementations, but if 80% of your effects come from 20% of your causes, then 80% of your revenue comes from 20% of your features, and they probably aren't the ones that are most used in your system.

2

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 believe that when people lament about tech debt, it's a misdirected complaint. Engineering teams will always be producing some amount of technical "debt." Even if we write beautiful, well-tested code that fits some noble architectural paradigm and meets every standard we can come up with, it is guaranteed to be deficient in some way--either now or to the team's (or our own personal) future views on what constitutes good code. When we write code, we come to some consensus as a team around what approaches we generally accept and what trade-offs we are generally willing to tolerate. And that's completely normal and unavoidable. But when we complain about tech debt, what we are actually complaining about is a deficient process. All software teams need to have dedicated time to revise our work. Far too often, we prioritize feature development over all other things. The end results of that deficient process are, invariably, twofold: a product with shiny new bells and whistles and a sea of spaghetti under the hood; and a team of stressed out engineers who have to work in a messy, frustrating codebase every single day.

19

11 Comments

Corporate IT has no place on the path to production. I see LOTS of portcos that hold onto shortcuts they took when they were small. Corp IT runs Jira, or email goes out through the corporate mail gateway. Call it technical debt if you like, and taking on technical debt makes sense when you're a startup. But when you've made it past that stage, it's time to pay it down. Corporate IT is incredibly valuable. I was the Director of IT before I decided to dedicate my career to production web operations. I knew my CDW rep very well. Corporate IT can handle: corporate email, Salesforce, Tableau, calendaring, Zoom, Dropbox, etc. Corporate IT cannot handle: production SMTP gateways, Jira, Confluence, GitLab, Launch Darkly, Datadog, Cloudbees, etc. I don't care in the slightest which actual vendors you use for these functions. I've seen corporate IT change SCMs to "save money" without any input from engineering and set the entire organization release schedules back by more than 8 months because it turns out that GitHub "runners" have security concerns. People have made changes to corporate email and suddenly customers no longer receive notifications, and no one in engineering knows why. Engineering (including Operations) is where the money is made in a software company, and they need to own the path to production. Think of it in terms of "chain of custody" considering the concern over supply chain attacks. In the chain of custody, we don't just let someone with completely different concerns handle evidence. Why would you? #devops #sre #engineering

63

11 Comments

I think it comes down to two things (1) it’s not enough to make businesses go faster, but rather make them move in the right direction (fast is nice too). (2) there is no evidence that Improving developer experience is necessary or sufficient to do (1) in a large fraction of cases. I don’t think this is a positioning problem - it’s more like a category error. #devex #flow #valuestreammanagement

5

6 Comments

Working on a specification for https://lnkd.in/g-pBfAQv. Then I can verify it with tests and https://blprnt.tech/. I'm reminded that wormwood is optimized for readable source code, not UX. There is very little syntax validation.

4

The development cycle https://lnkd.in/ggh5NTfh Posted on October 15, 2024 how to clean up code. run your code to make sure it works while (work_to_do){ make a small change test it commit to git } push to git server on local branch try it on another machine collapse git commits for code review test post for code review How to add a new feature run your code make sure it works while (work_to_do){ write a small test while (test doesn’t pass){ make a small change test it } commit to git } push to git server on local branch try it on another machine collapse git commits for code review test post for code review

2

Sound familiar? UX was laid bare CX is circling the drain EX was dead before it started DX? Let me make it make sense... 1. Companies don't care about people, they care about profits. That's it. There is no #2. And that's not a value judgement, I'm not criticizing companies for it. It's just a fact. Investments from companies require a simple, tractable, measurable, causal relationship to profit. PMF eats (insert initial)X for breakfast.

2

Posts that ATTEMPT to classify Software Developers get it wrong ALL THE TIME. Here's why... There is no 'customer focused engineer' or '10x ninja'. There are only two types: 1. Developers with no side projects. 2. Developers with unfinished side projects.

3

1 Comment

Measure what matters. I've written a 1000 lines of code before, demonstrated it, and then never touched it again. I've written a line of code that gets used over, and over, and over. Which is more important? Which hits the metrics? More importantly, which one is incentivized? Find ways to measure impact and outcomes. Everyone will thank you for it. And your software production will be incentivized around what matters.

9

It is CRAZY how much weaker OpenAI GPT-4o is at coding from the completions API than GPT-4. I'm not sure if this is the intended result, but very surprising nonetheless. The training recency is very evident, i.e. it knows about much more modern things, but the difference between its logical output is great with GPT-4 just thinking in a much more sophisticated fashion.

5

1 Comment

Nowadays we can find all over the internet, articles and YouTube videos showing you the basics of building a naive AI Retrieval Augmented Generation (RAG) solution. But very few mention the basics of the overall solution's architecture. Building robust, clean, and scalable architectures is paramount when developing RAG solutions. While they combine the best of retrieval-based and generative models, to enhance the quality and relevance of AI outputs, they have extensive computational requirements to process and generate content from multiple datasets. As an alternative to finetuning, RAG makes sure responses are tailored and contextual and putting a solution together can be achieved with a small team. But there is a significant difference between a naive RAG solution written on a Jupyter notebook and the needs of the enterprise. An enterprise RAG solution must interact with diverse data sources, manage complex dependencies between components and sometimes support a large number of concurrent requests. As such, it is important to consider a clean architecture to ensure the system is modular, easier to manage, test, and scale. A scalable architecture ensures that as the amount of data or users grows, the RAG system is able to handle the additional load w/out a drop in performance. A few important elements to keep in mind for those implementing RAG pipelines:     1.   Microservices: Breaking down your application into smaller, interconnected services rather than a single monolithic system can greatly enhance scalability and manageability.     2.   Cloud-First: Cloud platforms offer flexibility, scalability, and resiliency, facilitating the deployment of RAG solutions at large scale. If your industry and requirements permit, a cloud option is a no brainer.     3.   Caching: Implementing caching strategies at the retrieval stage can reduce latency, and LLM inference cost. Frequently requested data is stored temporarily and accessed quickly. 4.   Multi-Agent: For large corpus of documents, consider leveraging a set of agents to break data down into smaller chunks. Each agent should be able to summarize, search and analyze their assigned document(s) to answer queries. This is a more flexible reasoning compared to traditional "single agent" set up.  5.   Remove Unwanted Language: Implementing measures to sanitize, detect and prevent harmful or offensive language is becoming increasingly essential for organizations. Integrating with existing LLM security tools as part of your inference pipeline, in addition to reinforcement learning during the testing/tuning phases, addresses this concern.     6.   Monitor and Optimize: Continuous monitoring and tuning are crucial to ensure that the architecture remains efficient and cost-effective. Considering a clean architecture when developing a RAG solution is not merely a technical requirement but a strategic one as well. Make sure your teams keep these principles in mind when building your pipelines.

4

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