Mashrur Hossain

Automation folks: what's your favorite esignature tool? Specifically looking at options with a strong API/webhooks for status changes to document, custom field mapping, and reasonable pricing. Used to be a fan of PandaDoc, but they're moving all of the API to an "optional" feature of Enterprise (which doesn't work for most of our clients).

15

43 Comments

Donald Raab and I recently had a conversation about his upcoming book Eclipse Collections, Categorically, his 40 years of programming experience, and the sheer joy he still gets from writing code. Whether you’re looking to up your Java collections game, learn career or life lessons from an industry veteran, or just want to be entertained, tune in to my latest podcast episode (link to episode in the comments)

105

3 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

With DORA metrics, the precision matters more as the metrics matter less. It doesn't matter if the number lacks precision when it takes 30 days to get a change into production. You could be +/- 5 days, and you'd still be deploying "monthly". When you reduce this to less than a day and start measuring in hours, the lack of precision would mean the noise disguises the signal. However, you don't need to fix this as your constraint has likely moved elsewhere. #DevOps #Metrics

19

3 Comments

As per Brandon Suponchick, CTO of Aviture, in his session at the Kansas City Developer's Conference called "The Agile Architect: Building Product From The Trenches, Not The Tower," one of the many insights he shared was the importance of testing but even more foundational is that code needs to be testable. In order to have "architecture that evolves at the same pace as your business requirements," we need to start with code that is easy to test, and tests should be holistic and stable. If code design is poor and difficult test, our ability to change systems and deploy quickly will be limited. We need to be able to ensure our code will not break through sufficient tests. This includes unit tests. #KCDC #KCDC2024

18

**PODCAST ALERT** Welcome to this week's podcast, where Chris Westerhold and I delve into the critical aspects of enhancing developer experience. Prioritizing developer experience isn't just beneficial; it's essential in today's market. We explore the importance of understanding developers' challenges to boost productivity, reduce tech debt, and spark innovation. #techdebt #DevEx #DeveloperExperience #TechLeadership #productivity

4

I’m definitely a DFS type of Netflix Viewer #ai #machinelearning #artificalintelligence #datascience #tech #innovation #llm #languagemodel #NLP #textgeneration #textanalysis #RAG #RetrievalAugmentedGeneration #knowledgegraph #semanticsearch #informationretrieval #livecoding #coding #development #programming #softwareengineer #developer #huggingface #tensorflow #pytorch #python #jupyternotebook

4

I’m honored to kick off this series with none other than Barry Jones a fractional CTO with 22+ years of experience, to tackle a topic that so many teams struggle with: Why software estimation is broken. Episode: https://lnkd.in/gF5H29Sb In this episode, Barry breaks down: Why story points often do more harm than good The confusion and misalignment they create between teams and stakeholders A smarter way to approach estimation by focusing on task breakdowns and measuring queues instead. If you’re a CTO, developer, or product manager, you’ll benefit from Barry’s practical tips for improving your development process and avoiding the common pitfalls of traditional estimation methods. Check it out and let me know your thoughts!

20

2 Comments

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

Having a ton of fun writing an ORM for V2 of Case Kit. Typescript has such an incredible type system. I have autocompletion for column names, the ability to include relations, relations of relations, etc etc etc... all returning properly typed data (no classes in sight). It's been really satisfying seeing it coming together, and it's been great getting my hands dirty with some (relatively) complex generics. And to head off the obvious question… why aren’t I just using Prisma? Well there’s a couple of things I’m doing differently that I think are marginally better: there’s no code generation involved here, it’s just types (inspired by Drizzle); there’s no Rust binary you need to deploy, and it hews much closer to Postgres behaviour and syntax (the aim here is not to abstract away which database you’re using). But the real blocker to me using Prisma was that its extensions don’t support modifying queries of nested relations - a hard requirement for me due to the way I have multitenancy and soft deletes set up. It’s not shown in the video but the Case Kit ORM lets you write simple middleware that will be applied to every level of a nested query. Perfect for setting timestamps or adding clauses on tenant id or things like that.

21

🚀 Navigating the Sweet Spot in Software Development I've come to realize that clients mostly care about outcomes like fast deployment, happy customers, and fewer deployment hiccups. They don’t mind how I get there as long as I do. Results like increased deployment frequency, customer satisfaction, and decreased lead times matter. To achieve these, I use a mix of strategies – 1-1 interviews, pair/mob programming, design workshops, training seminars… you name it. But all of this is secondary. The real foundation? Our culture and attitude towards our work. As managers, we can't force attitude shifts, but we can change behaviors. Here are some behaviors that make a massive difference: - Test-driven development - Relentless refactoring - Probing until we nail the "done" definition - Frequent deployments - Continuous integration These behaviors not only lead to the stellar results we aim for but also foster a more collaborative and generative culture. In short: Change behaviors, and the attitudes (and results) will follow. Here’s to hitting that sweet middle ground where software just flourishes! 👉 How do you tackle the challenge of shifting team behaviors in your organization? Share your thoughts below! PS: bonus cat pic bellow! 🐱

3

I get this question occasionally: > How do you keep up with the pace of technological change? And my response is often something like that "the more things change, they more they stay the same". New technologies almost always are new implementations of existing patterns, and those patterns are *very* robust, holding up for decades. It doesn't take long to map some new thing onto pre-existing patterns and then finding what parts it hasn't implemented yet to identify what kinds of shortcomings it will have. When thinking about how to invest the limited time you have available for learning things, you'll get the highest return on that investment by focusing on knowledge with a long shelf life, rather than in things like "what's new in version X of technology Y". If you're looking for a course to not only cover those kinds of patterns but also show you when/where/how to connect which of those patterns together, with examples from domains like ecommerce, healthcare, insurance, and more, something that could hold up for the new decade of your career, maybe this could point you in the right direction: https://lnkd.in/dfftjeuT

85

6 Comments

This looks like a great project from my friend Haig Douzdjian. I hope that once he finishes the overview he posts some more details about how he processes the implicit feedback (without giving away all the jewels, of course!). Human-in-the-loop feedback is a critical need for #LLM-based systems, but just like with traditional tabular #ML it's really hard to get enough feedback (aka labelled data). Building models on the side, to watch a conversation with an LLM and evaluate the success of each prompt interaction, seems like a great idea. I have to wonder how to cut through the noisiness of the #data well enough to make it valuable to the model. Hmmmmm!

5

1 Comment

Do you think you need to hire developers as w2 employees to build a highly-skilled, devoted and culturally aligned team? Let Blueprint show you otherwise. Here's how we're changing the game: 1️⃣ Unmatched Quality: Quality is our creed. Our vetting process includes interviewing with former CTOs and senior software engineers, ensuring only top-tier talent makes it to your team. 2️⃣ Long-Term Commitment: Forget the turnover and churn worries! Our developers stay longer than industry norms for W2 developers (average tenure of 2.2 years), providing stability and continued expertise to your projects. 3️⃣ Cultural Integration: Culture isn't just an add-on for us. We dive deep to understand your core values and ensure every developer we match with your team enhances and embraces your company culture. 4️⃣ Equity is Optional: Save your cap table for your growing startup! We ensure that our developers are passionate believers in your product right from the start - without incentivizing them with equity. We rigorously test for craftsmanship, ensuring they value not just a quality end result but also the journey of creation. 🌟 Shoot us a DM to connect and see how we can improve your staffing strategy. #StaffAugmentation #InnovationInStaffing #TechTalent #CultureFit #LongTermGrowth

20

1 Comment

I've read many great books throughout my career, but these are the ones I find myself coming back to over and over again. Continual learning is a key part of being a strong software leader, and these are fantastic books to check out if you haven’t read them yet: - The Phoenix Project - The Unicorn Project - Accelerate - The DevOps Handbook - Crucial Conversations - Compelling Communicator - Turn the Ship Around! - Team of Teams - Wiring the Winning Organization - An Elegant Puzzle - The Power of a Positive Team - Making Work Visible

108

3 Comments

AMPP Up Your Communication: Ask, Mirror, Paraphrase, or Prime "To encourage others to share their paths we'll use four power listening tools that can help make it safe for other people to speak frankly. We call the four skills power listening tools because they are best remembered with the acronym AMPP-Ask, Mirror, Paraphrase, and Prime. Luckily, the tools work for both silence and violence games. ...To encourage the free flow of meaning and help others leave silence or violence behind, explore their Paths to Action. Start with an attitude of curiosity and patience. This helps restore safety. Then, use four powerful listening skills to retrace the other person's Path to Action to its origins. - Ask. Start by simply expressing interest in the other person's views.  - Mirror. Increase safety by respectfully acknowledging the emotions people appear to be feeling. - Paraphrase. As others begin to share part of their story, restate what you've heard to show not just that you understand, but also that it's safe for them to share what they're thinking. - Prime. If others continue to hold back, prime. Take your best guess at what they may be thinking and feeling. As you begin to share your views, remember: - Agree. Agree when you share views. - Build. If others leave something out, agree where you share views, then build. - Compare. When you do differ significantly, don't suggest others are wrong. Compare your two views." ― Crucial Conversations Tools for Talking When Stakes Are High https://lnkd.in/gn-vrUX #teaming #teamwork #team #teamcollaboration #ensembleprogramming #ensemble #mobprogramming #radicalcandor #interpersonalcommunication #interpersonalskills #interpersonalleadership #conflictresolution #understanding #agility #agile #selforganization #people #work #innovation #crossplatformdevelopment #crossplatform #mentalmodels #pairprogramming #extremeprogramming #modernagile #psychologicalsafety #continuousimprovement #collaboration Joseph Grenny, Ron McMillan, Al Switzler

3

2 Comments

My #1 management rule that I’ve seen even very senior people get wrong - people’s actions will mostly mirror how you treat them: If you treat devs like children with blinders on they will act like children. If you hide costs from devs they won’t care what things cost. If you don’t have devs on the hook for when things break they won’t care so much about when they break. If you treat office workers as untrustworthy they will act untrustworthy. If you force RTO to keep an eye on people they will waste more time in the office. The tighter you squeeze your fist the more falls through. Thats not to say there aren’t exceptions to this but it’s true in the general case.

57

10 Comments