Jared Fleener

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

Rails 7.2 now makes sure jobs get enqueued after the current database transaction is committed. Previously, your jobs would run before the records were saved to the database causing errors, so Rails takes care of it for you. If you've ever had to remind yourself (or your team) to use `after_create_commit` callbacks instead of `after_create`, this solves that problem. ActiveRecord uses transactions behind the scenes, so it's an easy mistake to make. And with jobs being retried, it's confusing why the job fails then succeeds a second later. This is another great example of conceptual compression in Rails! https://lnkd.in/gyNtiPnr #ruby #rubyonrails #rails

141

9 Comments

Agents are getting really really good at programming, try this agent out: https://buff.ly/4cY7vRk I use this agent every single day multiple times a day to build functions with documentation, error handling, and type validation. It's overpowered.

1

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

Do you develop trust in your interviews? If you're not in the software profession you probably do. Humans like building trust. Software "professionals" are rather inhuman because they work with keyboards all day. (I'm a software developer but I am a 40 year meditator with a psychology degree so I'm still human.) Can you believe that when devs meet, they quiz each other on trivia? Even worse, they quiz the interviewee on trivia that's already on their resume. How loudly can you scream, "I don't trust you!"??? That changes the entire working relationship! Let me show you via a study... Dan Aerily, the popular MIT and Harvard psychologist who studied lying, was asked to present some of his findings on Madison Avenue (fashion is purely deception about the value of material). After, Aerily asked them for a box of Prada sunglasses for experiments. For years he's been giving subjects tests to learn about deception. He knows about how much people will lie when, say, they're allowed to correct their own answers. In this experiment, Aerily gave two groups of subjects real Prada glasses to wear while they're doing the difficult test. He told them he wanted to see if these glasses would give them a better score. Of course that's not what he was really testing. One group was told that the real Prada glasses were fake. What happens to people when they are put in an untrusting environment? Will they lie more? Yes! the people who thought the glasses were fake lied more than the people who wore the real Prada glasses and knew they were real. Take a step back and you know that it's true. When you see that a person is trustworthy, you treat them with trust. When someone trusts you, you give them trust back. When you know that a person is untrustworthy, you're not going to hand them your trust easily. When someone doesn't trust you, you're not going to be ready to trust them back. Right? If someone hands you a resume and you start quizzing them on minutiae, you're showing them you don't trust the words they wrote. You are asking for the new employee to be an uncooperative slacker. They fooled you by studying for the quiz rather than doing actual work which they know is almost irrelevant to getting the next software job. If they like games like this, watch them play Agile poker. 😂 How did this untrusting environment develop in software but not other professions? I'll let you guess. I can assure you that 30 years ago, before we started quizzing each other, software developers worked much more cooperatively. It was like Gilligan's Island - everyone together working to get off. Nowadays it's like Survivor. Trust goes a long way and if you break the trust when you meet, you might never get it back. #psychology #team #trust #interview

3

2 Comments

I keep hearing the idea that pull requests are bad and that developers shouldn't do them. Well, to me, most of these arguments are somewhat of a straw man variety and they encourage throwing the baby out with the bathwater. Pull requests aren't the problem. Pull requests won't prevent you from doing continuous delivery. The problem is pull requests that take a long time to review and approve. This is the thing that will prevent you from doing continuous delivery. But this is a very avoidable problem. It doesn't have to be this way. In our team, PRs don't normally take long to review and things in the trunk are being updated regularly. So it was in my previous team in my previous place of work. I worked in at least three different teams where we would try to get rid of PRs to see what will happen. In all of those cases, we had to get back to doing PRs because removing them caused more problems that we were trying to solve by removing them. I get it. It may work for some teams that do pair programming all the time, which I see as the only way to keep the code quality up without the PRs. However, this approach will not suit every company and every developer. Many developers I know will find it exhausting having to pair-program all the time. Even when you pair program, PRs still have their use. Just before you push all those commits you created, you can create a PR to view all the challenges to make sure you haven't missed anything. You will not only be able to verify that no temporary code changes go in, but you will also create a nice audit trail of who made the change and who reviewed it. I even sometimes create a PR for my own changes because because it's a tool that makes a pre-push verification very convenient. PRs are just a tool. Just like any other tool, it can either be used or misused. It only causes problems when it's misused and not when it's used properly. This tool may not be useful to you, in which case you may discard it. But you may also find out that it's not as useless as some people say it is and it won't stop you from doing continuous delivery, as these people say.

38

26 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

"Never assume - it makes an ass of u and me". Except when estimating of course. "How long will it take?" has got to be the most annoying question anyone in software development can be asked. Totally get why. There are always tons of variables, especially at the beginning. If someone wants solid timelines, they might not really get how software dev works. But if you can't throw out an estimate with some clear hypotheses in place, you might not get how business works either. Trite though it is, "time is money" and "money doesn't grow on trees". So yeah, it's fair to estimate, but make sure you’ve got those assumptions clear. Assumptions are a big deal in any plan. Ignoring them is why plans fall apart. Look after your assumptions, or you might end up feeling like a bit of a donkey🐴

14

Caching is hard. So hard. But also, we are so fucking bad at it. Every time I have to use a public wifi setup I have a joker moment. Does absolutely nobody test shit on anything less than wired symmetric gigabit anymore? Web SPA apps are some of the worst for this. Motherfucker, you have the same fucking iconography for three years, why does it load correctly and then ALL OF THE ICONS FAIL ONCE I DROP TO A SHIT INTERNET CONNECTION?! I didn't even reload the page?! The fuck are you doing? But seriously, caching is hard, it's really hard, but you can make life WAY easier for yourselves when building an SPA if you do this super simple thing. Break down all your content into two axis: 1. push vs pull 2. owned vs user Whenever possible, turn your pull assets into push assets and all of your user assets into owned assets. What do I mean by that? Let's break it down further 👇 There's four categories: 1. Push + Owned 2. Push + User 3. Pull + Owned 4. Pull + User I'm making up terminology but fuck it, I'm drinking coffee and eating my donut and doing this live at a coffee donut shop, fuk it. Push means that the asset is pushed to a central server and then distributed. Pull means the asset is referenced and the central server has to "pull" the content. Owned means it's owned by the central server, user means it's user-submitted content. Every content caching strategy on the web fucks this up because the web isn't designed to handle this notion of push vs pull or user vs owned. However, the web *is* designed extraordinarily well to handle the concept of pull + owned, and with service workers, it's also extremely equipped to handle push + owned. So, make everything owned, and make it all push if possible, *especially* if it's an SPA. Push + Owned is weird, so: Content is pushed to a central server and then distributed. And it's owned by the central server. This is ideal, because it means that your expiration time can be infinite. You only expire content on the client when explicitly told to Got that? You. Only. Expire. Content. On. The. Client. When. Told. To. Make everything push + owned if you can. That means not returning a 304, it means not even trying the web request. Put that shit in STORAGE. UI icons are the classic example It turns out, however, that you can make a shit ton of other stuff push + owned if you try a little harder. User profile picture? If the user doesn't change their profile picture, it's guaranteed to be the same. Guess what fukers, expire the it on new upload but otherwise OWN IT. Custom emojis n shit? Own them. Expire them only when they're changed. "But Hazel how does the client check if they're expired?" Use "stale while re-validate". Ur welc' A concise summary: 1. Push + Owned: storage, stale while revalidate 2. Push + User: infinite TTL + hashed URL 3. Pull + Owned: infinite TTL + hashed URL 4. Pull + User: sensible semi-short TTL + stable URL Continued in my blog! Link in comments :)

61

20 Comments

Why I Broke Up with NavigationView for NavigationStack 💔 Me to NavigationView: "It’s not you, it’s me... Actually, no, it is you. You’re just too... outdated." 😬 💡 NavigationStack slides in: "I heard you like clean, predictable navigation. Let’s make your app drama-free." 🎉 Now, with NavigationStack, navigating between views is so smooth, it feels like I’m swiping on a dating app. No weird reloads, no confusion—just one view at a time. 📱 My app: "Finally, I can stop seeing my views fight each other for attention like it's the Hunger Games." 👀 PSA: If you’re still using NavigationView, it’s like using dial-up internet at a fiber-optic party. Time to upgrade before your code ghosts you! 😂 https://lnkd.in/err3bdJQ #iOSGlowUp #NavigationStackForever #NoMoreViewDrama #SwipeRightOnBetterNavigation

3

Automate your build & test with GitHub Actions they said. It'll be easy they said... That was 90 minutes of head scratching, mild cursing, and reinforcement of my belief that somebody other than me needs to be responsible for DevOps matters on any project I'm on. I do NOT have the right mind for this kind of work, and I get frustrated WAY too easily. The workflow is actually working now, but it was a SLOG to get there, and it was failing for (to me,) a stupid, stupid reason. Windows doesn't care if your directory and file names are cased differently from the way they're expressed in the solution or project files. Linux, on the other hand, loses its open source little mind. //TODO: Add another coding standard to the list, and find a way to lint this stuff, hopefully in an automated fashion. See y'all tomorrow. - #thatDeveloperDad #figuredItOut #liveCoding #liveBuilding

6

10 Comments

Will Devin AI replace developers? 😱 Maybe 🤷🏻‍♂️ To me personally, Devin is a development tool and not a replacement...YET 🌚 I am not denying that Devin can code really well if all the claims are accurate. Eventually, it may replace developers. But developers don’t code just to code. We build products ✅ We build solutions ✅ And these happen to be made of code. Can companies ditch all developers today and expect products to still get built and maintained to the same standard as an enterprise-level solution? Nope 🙅🏻‍♂️ The quality of a product refers to how well it solves user problems. And those gaps between code, user, and solution? That’s where good developers provide values 👨🏻‍💻✨

1

Copilot and development: What activities are easy to automate? Hear what Marcel Chabot - Development Manager at The TM Group, Inc. uses Github Copilot for: - Writing up to 50 lines of code - Clean up long and complex code - Write documentation - Explain what the code does How have you been using Github Copilot to make your job easier? Want to see the full 34min interview? Click the link in the comment section. Dynamics Compass #github #copilot #microsoftcopilot #msdynamics #microsoftdynamics #msdyn365 #d365

2

1 Comment

There were other examples of this around the web, but none explained _how_ automatic reloading worked in Django. Some implementations felt half-baked. I think this one stands apart. This is also my 70th blog post on DEV 😮 https://lnkd.in/gtC6sBMr

3

2 Comments

I've seen a lot of bugs. (No, not another cicada post). Software here. Egregious, immediately noticeable bugs. The opposite - those that require 6 concurrent conditions and 6 hairs from your nextdoor neighbor and it still only triggers once a month. (Okay, 7 conditions, 6 hairs...don't split those hairs). A continuum of buggage. Those complicated ones, sans the hyperbole - those are your Zero day issues. Regression testing doesn't find them. A super wily code-reviewing look-at-it-all software QA professional (I know the best one)...might...but probably not. How do we even engineer testing all of the complicated conditions? The interrelationships at runtime? I don't see a lot of talk about "how could we have caught this?" in public for disclosed issues. Most of the fixes for Zero days (those security holes best known because they're patched with updates to software like Google Chrome browser, Apple's ioS, Microsoft Windows) are downplayed. You get "Hey, user, look at these new features you're getting, and in whispered voice, "and security updates." Not familiar with the term? Zero day means a security issue without a patch. When the patch arrives, there's a remedy for the problem. Users often don't APPLY the remedy until much later...its own problem...prolonging the risk of the Zero day issue. Back to my kinda silly example. That's a wicked hard problem to test for. A bunch of concurrent situations that then trigger the problem. But, when the problem's a known issue, it's not hard to re-trigger. And therefore exploit. So what do we do? Other than fixing/patching, and communicating? What else is there to add to this conversation? Sunday thoughts. Sunday thoughts.

13

7 Comments

Agree. Building home grown tooling is expensive. Try Caliper to get gain visibility into your cost and usage of Datadog environment to ensure you are great value for your investment. Don’t spend a lot of money to find out where you’re spending a lot of money.

1

Unpopular opinion: It's not the software devs who need convincing. Selling devs on TBD, TDD, CI/CD, and ensemble programming, is a waste of time. We need instead to focus on continuous feedback. We need to sell it to the higher ups. To the people who call the shots. Because in the end, the aim of these tools and processes is to decrease the time it takes for us to collect valuable feedback from customers. Once the c-level people are sold on the merits of fast feedback, software devs will quickly learn how to write and deliver quality code.

6

4 Comments

Can someone explain to me how to get "more experience"? I have 16 years of full stack software engineering experience, mostly in C# .Net 4.2 through 8, including .Net Core 2.x & 3.x, along with WCF, WPF, Winforms, Razor/Blazor, HTML, CSS, and JavaScript, with Entity Framework, Dapper, Linq, SQL Server, MySQL, SQLite, Oracle, NoSql, and other databases. And a few of those years include a combination of Java, PHP, and C/C++. I've also used MarkDown, PowerShell, MVC framework, Swashbuckle/Swagger, Newtonsoft, JSON .Net, TopShelf, and a variety of testing frameworks. But apparently that's not enough. In the past 3 years alone, I've learned ReactJS, TypeScript, Xamarin, XAML, Maui, NodeJS, Terraform, AWS, and Azure, and I'm currently learning Angular, but that doesn't cover the 3-5 years of experience jobs want. I've learned some of these skills through jobs, but also some on my own. Except that as often as companies want us to learn these skills outside of work, they only count professional experience when it comes to hiring. My last interview said I needed more experience, as if the previously mentioned 16 years wasn't enough, and neither was the 15 years of computer repair and networking before that, which their interview questions also covered. So if no one is willing to hire because people don't already have experience, how are we supposed to get the experience? And don't say "open source projects", because they don't count as professional experience. Or do I have to take a 50% pay cut to take an "entry level" job that still requires 3-5 years of experience that I somehow still don't have? People are quick to say that "no one wants to work anymore" when they can't get hired, but they never seem to think "businesses aren't willing to teach anymore" when they refuse to hire people. Why? Is it that we are so conditioned to think that it's always the individuals fault for not living up to expectations, instead of the businesses fault for setting unrealistic and ever changing expectations? So, I ask again, how can I get the required experience when employers refuse to hire unless I already have experience?

2

If celebrating software maintenance is something you want to do, you should check out the Legacy Code Rocks conference MenderCon on May 16th! I’ll be giving the opening keynote: “Community Is Just as Important as Code” Registration link is in the comments.

25

2 Comments