Jakie W. Rice

Time to be fair.... In past posts, I have been less than complimentary of the DLC regulations that now make it more difficult to implement SMS into an application. I understand that all sorts of organizations use (and misuse) SMS millions (billions?) of times daily. I get that the new regulations make an attempt to reduce, as much as possible, SMS Spam. All in all, it just seemed like another example of hand-cuffing the good guys while trying to put some limits on the bad actors. My experience at the time was with #Twilio... and I tried to make it very clear that my frustration wasn't necessarily with them - they were doing the best they could to handle an avalanche of organizations trying to comply with new rules that everyone was stumbling their way through. I've been using Twilio for years and can't complain AT ALL about the platform performance for my particular small-scale needs. It was the nearly impossible approval process that really soured me. After nearly a year of living without application-based SMS (email only), I decided to revisit. The application was already all wired up for the feature - it was just dormant. This time around I was able to get up and running in 3 days... 99% of which was the DLC approval - which happened today. Kudos #Twilio for suffering through the tough days and making SMS once again something that can be done with very little pain. #twilio #sms #dlcapproval

2

An RPG leveling tree for Technical Program Managers 🧌 You can also check out the SWE, DevOps, and EM leveling trees in my previous posts. QA coming soon.

1

A few controversial things I believe about writing code: 1) Code should be comforting, not just functional. I’m not saying it should be flowery or overcomplicated. I’m just saying it should be easy to read and pleasant to navigate. 2) Comments should be personal. Contrary to popular belief, dry comments are a waste of time. “Initializes variable.” “Checks condition.” “Executes loop.” Generic comments are hard to remember and easily overlooked. 3) Humor belongs in your code. “Most people” keep their code dry and formal. Which leads to… Boring code. Disengaged devs. Missed opportunities for connection. Clearly, what “most people” do doesn’t work. So, add a little personality. 4) Consistent formatting isn’t negotiable. 99% of the time, neglecting formatting is a giant mistake. Instead, Robert Martin’s “Clean Code” framework offers a path to elegance without clutter. Consistent naming conventions. Proper indentation. Thoughtful use of whitespace. 5) Pursuing code efficiency at all costs is a silly goal. Because readability and maintainability often matter more. Code that’s easy to understand is a better pursuit in life. It saves time. It reduces errors. It fosters collaboration. If we all have to spend time there anyway, why not make it nice? In a world of deadlines and conflicting requirements, your code can be a refuge, a place of quiet contemplation. 🪷 Read this post and more on my Typeshare Social Blog: https://lnkd.in/gjZbQJrP

8

Job Hunter Tip #7: When crafting your resume, don't just list your job duties; make it personal and impactful. Highlight what you specifically achieved in your role that made you stand out. Focus on measurable outcomes and unique contributions. Instead of saying what someone in your position typically does, showcase how your actions drove success, solved problems, or brought value to your team or company. Don't be afraid to own your success.

10

1 Comment

100% agree that focus on quality is actually faster to deliver *working* software, and that the the tradeoff is often poorly articulated. The focus on quality leads to projects that have a lot less drama and grey hairs that than the alternative. No one has the "I will deliver Tuesday but it won't work, is that ok" to an exec demanding delivery, though that is the actual promise being made. When you look at mid and long term outcomes the difference becomes *very* apparent, but the advice in consultancy terms is be conservative in the promise as offering anything over 10% saving / reduction will be treated sceptically. Typically the last three projects that focused on 'rapid delivery' not quality broke their estimates by typically 50% until the eventual client had something they could actually use... but this gets forgotten in the moment in a tragic bout of collective amnesia when the next project is being discussed. I posit that one of the underestimated mechanisms why this is true is that it exposes many of the 'project killer' type issues early as the pragmatic building of TDD / BDD / Perf & Load Testing contributes to early transparency of gaps in understanding of requirements, and exposes broken assumptions.

2

Struggling with efficiently managing your software engineers for your company? Wish you had a way to retain your best engineers and get your projects delivered on time? Let’s chat. I’ve built and run several large teams with the highest retention and efficiency in my divisions.

9

Re: Comments & Function/Class sizes: What is described in „A philosophy of software design“ does make a lot more sense to me than the rules popularised by (not my) Uncle Bob. The author advocates for comments in the right places and does not put arbitrary rules around how long something should be in place and rather takes a different approach based on foundational principles. I’m really enjoying that book more and more. It describes very well what I learned the hard way in 15+ years of writing software.

8

1 Comment