Daniel Trinidad

High-Performance Teams Fail Without This One System I saw this when a startup lost two 2 senior engineers in 6 months. These engineers were part of the core team and were good at what they did. But when they left, so did critical knowledge and framework that took years to develop. It almost felt like their engineering team was starting from scratch again So, if you have(or are building) a talent dense team, ensure you also focus on high-performance systems that compound/sustain output. These 3 steps are a good starting point: 1/ Treat decisions like assets The best teams log every major decision: what they did, why, and the trade-offs. This prevents repetitive debates and accelerates onboarding for new members. 2/ Codify workflows into playbooks 3/ Building a rhythm for knowledge-sharing This is something that most teams overlook. From post-mortems to team debriefs, the goal is to keep insights flowing. Don't let this be sporadic.

19

1 Comment

Engineering Managers are losing hundreds of hours a month without making a successful hire🫨 I spoke with 5 separate Director/Head's of Engineering this week who told me that their hiring process has cost them and their teams over 100 hours a month; but here is the real sticking point⬇️ They screened and interviewed hundreds of applicants, but have still not hired the Software/Platform Engineer they are looking for🤨 Some of these engineering positions have been open for over 6 months... The issues?⬇️ ➡️Their job adverts are too vague and do not accurately explain the position and critical skills needed ➡️In turn, they receive hundreds of unsuitable applications that are still screened ➡️They rely heavily on inbound applications and do not map the market and headhunt in anyway at all ➡️They had an expectation that they could hire for free with the influx of available applicants; but did not calculate the cost in time and productivity in not making a successful hire relying on this method alone ➡️Their organisation was not marketing themselves to the wider engineering community so ultimately 95% of the suitable candidates didn't even know their company existed ➡️External hiring budgets are constrained and the "need to save money" was out weighing the "need to hire the right person quickly" For niche, expert level Software & Platform engineering positions, hiring the best people is still challenging. Relying only on the above methods is creating bad candidate experiences and costing huge amounts of time that could be put to better use elsewhere. The issues mentioned above need to be addressed if organisations want to create a efficient and successful hiring model. This approach I have highlighted will not work forever and is not sustainable. #hiring #engineering #activesourcing #candidateexperience

7

I tried arguing a point about TDD today and fell flat on my face. I was corrected by the OP after I had (incorrectly) said that TDD allows you to test the behaviour of the system, when in fact it is the tests that do this and not the process of TDD itself. The annoying thing is I know this, but in the moment failed to string together my point correctly and said the wrong thing. Just another classic example of how articulating your point and a bit of proof reading goes a long way, or you lose all credibility in your argument. 😅 I think this is the first TDD debate I’ve involved myself in on LinkedIn, and likely the last. I’ll stick to complaining about the job market, pushing for better mental health and general leadership stuff. #fail #humbled

24

24 Comments

Programming tests are: ❌ Often stressful ❌ Take-home tests are usually time-consuming ❌ Rarely representative of the approach and conditions of the job that they're testing for ❌ Many times online code testing platforms will penalise you for clicking away from the screen and sometimes they penalise you for any copying and pasting ❌ Usually theoretical "best practice" based - showing how you might do something if you were working in a vacuum, not accounting for business needs / interdependencies with legacy platforms etc ❌ Typically they favour those who have more recently come from education over more seasoned professionals ❌ In some cases the results are ignored or overlooked anyway if the candidate has done well enough in interviews rendering the test itself pointless ❌ In other cases companies take a "line in the sand", "computer says no" approach where even someone who is a known entity to the team or business will be rejected if they don't do well enough on the test   I have NEVER heard a developer say that they enjoy technical tests.   Some of the most senior, capable, accomplished developers I have worked with refuse to complete them as part of a process - particularly timed ones.   How often do you write code in a real life production environment with a timer counting down? And when would you ever want your team to not have access to Google or GitHub or Stack Overflow on a difficult task? A significant part of an Engineer's role is to research potential solutions critically, not to be a walking programming encyclopedia!   Even if your test is a less pressured, more representative take-home task rather than a recorded or monitored time-pressured task, they're not always that informative and they often take up a large chunk of time, which, particularly for someone who is currently in full-time employment and interviewing for multiple other opportunities, is a lot to ask. They also often lead to excellent candidates withdrawing from the process.   To quote a senior dev I spoke to the other day: "It doesn't matter how great the pay or the company or the work are. I'm a professional with over 10 years' experience, treat me like it. Don't set me bullsh1t homework"     👉 So why is it that so many interview processes use them? 👉 And what are the genuine legitimate alternative approaches to be able to ascertain someone's technical capability?   Keen to hear your thoughts Linkedin? Futura Talent #technicaltesting #techrecruitment #developerlife #softwaredeveloper #softwareengineer

8

2 Comments

There’s a fascinating ‘leaked’ PDF[1] doing the rounds at the moment. It, allegedly, was penned by Mr Beast, and in it, he outlines key factors for success at his production company. I’d recommend reading it as he speaks with great candour, and it’s packed with broadly applicable insights, but my personal favourite is this: === USE CONSULTANTS Consultants are literally cheat codes. Need to make the world’s largest slice of cake? Start off by calling the person who made the previous world’s largest slice of cake lol. He’s already done countless tests and can save you weeks worth of work. === Whenever I’ve mentored people who wanted to start out in consultancy, I’ve always said the same thing: a consultant is just someone who’s done something at least once more than their client. Consultants aren’t there to be smarter than their clients—they’re there because they’ve BEEN dumber. Consultants have already seen and made all of the right mistakes in all of the right permutations, and they’re there to stop their clients from doing the same. Your client CAN DO what you do—you’re not special. It’s just going to take them longer. You’re not hired because you know what to do—it’s because you also know what not to do. You’re not special; you’re a shortcut. 1. https://lnkd.in/eD6SYchZ

111

6 Comments

Too many 'software engineers' today are glorified code monkeys. Harsh? Maybe. True? Absolutely. - 90% can't explain how their code runs in production - 95% have never touched a database outside their ORM - 99% think 'infrastructure' is someone else's problem News flash: AI is coming for your job, one-trick pony. The future belongs to the curious. The explorers. The 'how does this whole thing work' nerds. Why? Because they'll be conducting the AI symphony while you're still tuning your one-string banjo. Here’s 4 signs you're on the endangered list: 1. Your knowledge of DevOps doesn’t go beyond merging your own PR 2. You've never SSH'd into a server (it's not a disease, I promise) 3. Your debugging process is 'console.log' and pray 4. You think scaling means adding more if-else statements Embrace curiosity. Break things. Ask 'why' until your team wants to mute you on Slack. Because in the AI future, the curious engineer doesn't just survive. They thrive. P.S. If this post made you angry, you might be a code monkey. Don't worry, there's still time to evolve. 🐒→🧑‍💻

145

45 Comments

Is your coding challenge costing you the best developers? Picture this: A brilliant developer, perfect for your team, closes your coding test tab... and never looks back. Ouch. Feels like a missed opportunity, doesn't it? Here's the kicker: 58% of developers say they've abandoned an application due to an unfair coding challenge, according to a 2023 Stack Overflow survey. That's more than half of your potential dream team... gone. But why? Aren't coding challenges the gold standard for assessing tech talent? Not quite. Let's break it down: • Time constraints stress out even the best coders • Generic problems don't reflect real-world scenarios • Anxiety can cloud true abilities • One-size-fits-all approaches ignore diverse skill sets The result? You might be filtering out innovative problem-solvers who don't perform well under artificial pressure. So, what's the alternative? 🔹 Take-home projects that mimic real work 🔹 Pair programming sessions 🔹 Code review discussions 🔹 Portfolio assessments Remember: You're not just testing coding skills. You're evaluating a potential team member. How do you assess technical skills in your hiring process? Share your approach! Let's build better hiring practices together. #TechHiring #SoftwareDevelopment #RecruitmentStrategy #CodingChallenges #TalentAcquisition

39

15 Comments

🔥🔥🔥amazing software engineering posts from the past week🔥🔥🔥 Ryan Murphy rejection means only that: rejection. Keep going. https://lnkd.in/ecfy5tBV Tiger Abrodi consistently posting TypeScript knowledge bombs https://lnkd.in/ebeapvQ9 Taha Hussain are you fueling the micromanager in your life?? https://lnkd.in/eFtrhiHN Eric Roby please keep your processes simple! your success depends on it! https://lnkd.in/epk7Q_qJ Owain Lewis principles for a delegation: I needed this 2 years ago. https://lnkd.in/eNvt564u Pramoda Vyasarao master the basics https://lnkd.in/eMKTMesj Matt Watson new, "exciting" and complex tech excites only one person: the person who uses it to build. long term success needs tech that is boring, known and comes with a talent pool. https://lnkd.in/e8aK9aQt Austin Belcak above average results require above average effort. Go the extra mile - the road is never crowded. https://lnkd.in/edWQGDPH Francis Nayan take. action. today! https://lnkd.in/ej-HbcpJ Callie Buruchara 7 principles for giving feedback. it's easy to see that Callie is leading from experience! https://lnkd.in/e9XXnDyq

29

Currently rinsing the team of a scaleup that has their devs on call 24/7. (Keep asking them to do it, they love it, trust me, why would I lie...) Genuine question - why on earth would you ask your devs to do 24/7 on call? Surely you know that nobody who respects themselves is doing that right? You are aware that developers exist in other timezones and you can employ them too right? "But we can't get the quality outside of Australia" 1. Yes you can. The best Australian devs don't even work in Australia. 2. The devs who will agree to do long term 24/7 on call aren't high quality anyway. I can't see any world where it makes sense... Can you?

20

17 Comments

Code readability: prefixes. If you've got a method which checks if a status is true or false, instead of calling it 'status', why not try 'isStatus' or 'isPending'? If you've got a method which checks if someone has replied, don't call it 'replied', call it 'hasReplied'. In my opinion, it's better to hint at whats being returned. Lots of micro-improvements like this make your code easier to read.

9

4 Comments

What is a TypeScript Engineer? I keep seeing this pop up in recruitment posts, which means clients are asking for it...right? Has this replaced the FullStack Engineer, which, lets be honest, meant a NodeJS developer. That was back in the good old days when it was only NodeJS. Now we have Bun, Deno, Hono and more. Or perhaps its asking for a Javascript developer...whatever that means in todays world of a thousand js frameworks and evolving ES standards. Or are they actually asking for a Java developer, because someones used Gen AI along the way and it got confused between Java and Javascript (*shudders*) Are they seriously in need of a type system engineer, thats kinda niche. It's hard enough trying to explain what you do as a job to "normal" folk as it is, without this level of obfuscation. How would you even explain this when asked "What do you do?". Do kids nowadays needs to consider themselves experts in everything inside package.json to land a job? When will the industry move beyond this fixation on specific languages? I get it, it's an important consideration, but asking for Typescript Engineers...it's not going to help you find the devs you actually need.

14

7 Comments

Talking with loads of #ios and #android engineers and leaders since my return from holiday last week. It seems there's still lots of questions around how long will it take the market to pick up! I'm getting asked 'Is it just the iOS market that's slow?' Err no, certainly not. 'Will the Android market pick up this year?' I don't have a crystal ball, but I do have optimism. "It cant stay slow forever!" I reassure them. There will be a bounceback! Let's talk..... When do you think the iOS and Android recruitment market will pick up? Are you already seeing the greenshoots of recovery? Have you got some inspirational words of positive stories to share with your fellow devs? Please let me know when you're commenting whether you're in the UK, Ireland or Europe! #androidengineer #iosengineer #uktechjobs #mobileapps #bounceback

15

4 Comments

CTOs: Are you achieving a 96% retention rate within your software engineering team? Last week, I met with the CTO of a startup, who told me how he is retaining his top-performing engineers He stressed these 4 key points... ✅He proactively presents opportunities for career development whilst remaining transparent in terms of expectations ✅He keeps his finger on the pulse in terms of market rates and ensures he pays at least 10% over market ✅He communicates regularly and signals business health often, especially during challenging times ✅He focuses on three intrinsic elements to motivate engineers: autonomy, purpose & mastery What else can you add to this list to help other CTOs retain their best engineers?

15

10 Comments

Looking for a reason to hire junior developers? Ignoring them is a big mistake, as John Crickett correctly points out. 👇 Sure, they might lack experience. However don't mistake their inexperience for incapacity. ➕ Their fresh eyes unravel new perspectives on old problems. ➕ Their hunger for learning is unmatchable. ➕ They're innovative, adaptable, and ready to absorb knowledge. Investing in junior talent is investing in the future of your business. 𝗧𝗼𝗱𝗮𝘆'𝘀 𝗷𝘂𝗻𝗶𝗼𝗿 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗮𝗿𝗲 𝘁𝗼𝗺𝗼𝗿𝗿𝗼𝘄'𝘀 𝘁𝗲𝗰𝗵 𝗹𝗲𝗮𝗱𝗲𝗿𝘀. So, next time there's a position open, consider them. You might just be surprised.

37

Want to watch me build an app in 30 minutes at SXSW London? 👀 Only joking… sort of. The way we code and build apps is changing FAST, and I think its super important that engineers are keeping up with the most up to date workflows and tools. Tools like Copilot and Cursor are making development faster, smarter, and more accessible than ever. At SXSW London, I want to show you how to harness these tools for your own projects. My hands-on talk will explore the AI transforming app development and what it means for the future of our industry. But I need your vote to make it happen. ➡️ Sign up for a SXSW voting account and hit the heart on my session page here: https://lnkd.in/eRmSSUnu

26

I often get asked about tech stack recommendations and I'm always quick to point out that I don't really know this stuff like a dev would. BUT... As a start-up, part of your future success relies on scaling quickly with people who can hit the ground running. Certain tools are going to make that task extremely difficult for you, and that's something to bear in mind. - Angular (all versions) - Ruby - Flutter Three tools that I would steer clear of at all costs if you're building a tech start-up of your own. Candidate availability (particularly those with start-up experinece) is just NOT there in this country. With Angular & Ruby, it's getting worse with time. Most candidates with experience want to move away from both tools and pick up things like React and Node or Python. With Flutter - it's supposed to be killing off React Native, but it's just not, and nobody wants to use it for Web. Maybe that'll change in time but for now, it's not the tool for a fast growth start-up. Just my 2 cents 🤷🏻‍♂️

39

58 Comments

Great talk by Dave Farley here: https://lnkd.in/eg4yERRW He covers the concepts of scientific experimental approaches to software engineering and how building quality in through the right level of abstractions can help us to take an incremental, experimental approach based on empirical evidence. This is why quality isn't expensive - actually, when done properly, a quality software foundation can open up new business opportunities. "The quality of a system is defined by our ability to change it!"

69

8 Comments