Justin B.

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

💥 Stop Calling Yourself a React Engineer! 💥 You’re not a Java Engineer. You’re not a Python Engineer. You’re not a Kubernetes Engineer. You’re not a GraphQL Engineer. You’re a Software Engineer. 🧠💻 When you define yourself by tools, you shrink your potential. Tools change. Frameworks fade. But your problem-solving skills? They’re forever. 🕰️✨ Great engineers are known for the systems they build, the challenges they conquer, and the impact they create—not the tech stack they use. 🌟🔧 In a fast-changing industry, today’s trendiest tools will soon be history. But your ability to adapt and innovate? That’s what sets you apart. 🚀🔥 So stop boxing yourself in by labels. Own your craft. Solve problems. Change the game. You’re not just an engineer—you’re a creator. 💡💪 #EngineeringExcellence #ProblemSolvers #ThinkBig #TechMindset

17

I was reading this article and thought to speak my mind on the matter. As a software engineer that has personally dealt with UTC related issues, I have a harder time seeing the value for storing timestamps in the user’s local time zone. This comes from several personal experiences when attempting to reference the data when it is stored in each way. Storing timestamps in UTC can be seen as greatly beneficial. When a timestamp is stored in UTC, that value can be understood as a single reference point that can be applied to any region in the world. The only adjustment you need is to apply the user’s time zone offset. In my own experience, you still must be forward thinking about instances such as states with several time zones and potential adjustments for daylight savings. In very rare cases, the storage of UTC values can come with too much variablility than it’s worth. If a timestamp is being stored for strictly the user, then it might be considered a better practice to store the timestamp locally. This can result in reduce function calls as well as mitigating possible scenarios of displaying the wrong date/time. However, if that timestamp needs to be referenced in a different time zone, then you must adjust for the difference. Achieved by converting it to UTC by stripping the local offset then applying the user’s offset or by comparing the two time zones and adjust it accordingly. In my professional opinion, software engineers should consider the storage of timestamp values in UTC as the gold standard. It gives the engineer more flexibility to utilize the value in different regions by applying a single offset. When attempting to troubleshoot a difference in a date/time, it is easier to identify where the miscalculation occurs.

2

1 Comment

Okay, software engineering hot take: not all timestamps should be stored as UTC. Some should be stored in the users local timezone, with offset. That way you don't lose the local information of when that user experienced the event. Say I take some medication at roughly 2 PM every day. I'm UTC-5. So if you convert that event to a UTC timestamp, it'll be 1900. Now I travel to Senegal, so my local timezone is GMT. If I read the Chicago event without the timezone, my default would be to convert it to my current timezone, so it looks like the event happened at 7 PM. What was I thinking that day, taking my meds five hours late?! UTC is good for comparing timestamps, standardization, and distributed systems. For human-facing information, though, the timezone is important information. Don't throw it away.

239

153 Comments

You'd think that after 15+ years I'd be safe from null reference exceptions... Null always comes back to bite though! I was working in my ASP NET Core app and had written a method signature that allowed nulls to be returned. I was using a custom result type that allowed for the result value (or null) or an exception to come back. However, the calling code that I wrote never had any handling for null to come back! Guess what happened? Boom. We can never be *too* careful around null! 👇Check the comments for the full video!👇 ---- 🎬 Check out Dev Leader on YouTube for multiple full-length videos weekly! 🗣️ Share with your network! #CSharp #ASPNet #ASPNETCore #DotNet

21

23 Comments

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

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

🔥 The "Clean Code" Lie That's Killing Your Career Most developers obsess over pristine code... While their colleagues ship features and get promoted. Here's the uncomfortable truth: Your perfectly refactored methods won't matter when your project is 6 months behind schedule. The real OG developers follow these principles instead: 1. Ship fast, clean up later 2. Focus on business impact over code beauty 3. Embrace "good enough" solutions 4. Save refactoring for critical paths only 5. Prioritize user value over technical elegance The hard reality? Your CEO is never excited about a perfectly structured codebase. They care about results. *** 🎯 Today's Challenge: Look at your current project. What quick-win feature could you ship this week if you stopped obsessing over perfect code? Share your commitment below 👇 *** P.S. Yes, I wrote this while staring at my own over engineered codebase I swear I'll refactor "next sprint." We're all works in progress. Hit that 🔔 on your way out if you have a "TODO: Clean this up later" comment from 2022 somewhere in production.

148

116 Comments

There are many "consultancies" out there who ask for the last 4 of your SSN, even before you've interviewed with them. Please beware of them, especially new grads/or folks desperate in this market. The only good time to share it is when the offer is on the table, and a background check is to be done.

29

1 Comment

Cognito doesn't support multi-region user pools (yet), but maybe we can get there ourselves 🤔 Let's do a thought experiment together. An API Gateway authorizer has a "ProviderARNs" attribute, where you can reference more than one Cognito User Pools. These are ARNs, so one assumes it can reference a user pool in another region. Cognito's "Post confirmation" hook is fired after a signed-up user confirms their user account. This invokes a Lambda function with the "userAttributes" and "clientMetadata". We can use the information in the payload to create the user in the other region. BUT, we don't have the user's password. If we DON'T use passwords, then that will not be a problem. That is, we go passwordless authentication. For example: * with one-time passwords: https://lnkd.in/ec839rFR * or with magic links: https://lnkd.in/erbGGBJ2 If we don't use passwords, then we can just set a random value when we create the user in the other region. In the frontend, the user will be able to log in with either user pool, and the JWT token can be used to access APIs in either region. What if the Cognito service is down in one of the regions? The whole point is to provide higher redundancy, but if Cognito is down in one region then synchronization is broken. You introduce a fallback. If we can't synchronously add a user to the other region's user pool, then we push a message in a SQS queue. A Lambda function is subscribed to the queue and will retry the failed operation N times before moving the message to the DLQ for further investigation and manual retries. Do you think this will work? There are a few constraints - we have to use API Gateway REST APIs and passwordless authentication - but under these conditions, it feels like a workable solution. Would you like to see me POC this? #aws #serverless #cognito

128

31 Comments

Should the entire development team attend all of the sprint events? No, because it’s inefficient and a waste of time. Right? Years ago I battled a tough client who didn't want the developers to attend the Sprint Review. He wanted them to, in his words, “just keep coding”. I argued…how will the team learn about what the customer and the business needs? His predictable answer was “better requirements documentation”. Software engineers are professionals who need to deeply understand the problems to be solve. The intent of sprint events is to provide context for these problems and enable collaboration. Ask your developers if they are receiving value from sprint events. If not, don't exclude them. Fix the events so they enable the development team. #scrum #agile #collaboration

2

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

Estimating software dev tasks is easy. 1. Guess how long it'll take you. 2. Multiply that number by 8. 3. Say that out loud. 4. Your boss will go WHOA THAT SOUNDS LIKE WAY TOO MUCH. 5. Your boss will overrule this and estimate how long it would take them (incorrectly). 6. Now it's still wrong but at least it's your bosses fault.

591

47 Comments

Developers rely on staying productive. Here's my 4 step framework for avoiding distractions: - Plan your work before you start writing code - Mute notifications during your focus sessions - Block off time in your calendar for focus sessions - Batch any non-code tasks (emails, messages, documentation) Be strict during your focus sessions. Watch your output soar.

230

15 Comments

Most people misunderstand software architecture documentation. They've been misled their whole careers. Lengthy documentation Perfect diagrams Polished presentations "Cramming it in" at the end of the project. I guarantee none of that will create useful, trusted documentation. The most successful software architects I know? They're building documentation workflows that: - Evolve with the architecture - Save time by staying practical - Focus on clarity over perfection - Support team alignment No documentation graveyards. No stating of the obvious. No last-minute stress. No wasted effort. They're "paid" differently: Reduced rework. Aligned teams. Better decision-making. Clearer communication. Respected expertise. They don't measure their success in how "complete" their documentation is. They measure it by how effectively it helps their team deliver. Want to create documentation that works for you, not against you? Join my "Master Software Architecture" program to learn practical approaches to documentation and more. #SoftwareArchitecture #Documentation #Learning

6