Bart van den Burg

9/10 times, there is only one reason that developers fail their take-home tech tests - and it has the simplest solution. "Coding projects are a polarizing topic: some candidates love them while other candidates find them unfair. On one side, coding projects allow you to showcase your skills in a more natural environment, using the tools you love." Love them or hate them, they're a non-negotiable part of numerous development interview processes. I completely agree that these tech challenges should always be general tests so that applicants are not expected to provide free contributions to the client's platform, but there is one huge point missed in this article. TEST YOUR CODE! The most common feedback I’ve had for why a candidate has been unsuccessful with their tech challenge is “code does not compile”. If you’ve taken the time to complete a tech challenge, it is imperative that you check to see if it works. You may have spent 3 hours on it, maybe even longer; don’t skimp on Unit testing. https://lnkd.in/dP4Nd5u2

21

5 Comments

I'm observing a team writing code as an ensemble without TDD. I am selfishly delighted in the confirmation of how valuable TDD is to me as I use it. The team is implementing a new function that's doing list of list manipulation and returning something. They are all over the place with naming things, creating objects, streaming, mapping, flattening maps, return object, variables, naming...so many squirrels. Too many squirrels to even really focus on "what's the simplest first thing we could do?" TDD is so much more than writing a test first. It's a framework that helps me focus, prioritize, structure, and order my thoughts. Test Driven Development is an immensely helpful design and focus tool. I should also note, that I am beginning of working with this team and meeting them where they are. #codelife #devlife #TDD #testdrivendevelopment #unittesting #designthinking #problemsolving #structuredthinking #focus #mindset #toomanysquirrels #codingchaos

282

62 Comments

I just watched Daniel Terhorst-North's talk at Kotlin conf, having sadly missed it in person (nothing to do with being hungover on day two of the conference). Daniel is the originator of Behaviour-Driven Development and gave a talk titled 'The best programmer I know'. A few interesting takeaways: - You don't need a degree to be an exceptional programmer - Everyone is a kinesthetic learner. Some people might lean towards seeing or hearing things, but everyone learns through doing, so just start and iterate as you go. Lean into uncertainty. - Invest in the product - not the code - Watch your users and find out what frustrates them - TDD pays off. Daniel's team at BP won a software quality award for their trading system. Unlike other teams, they found zero bugs during six weeks of UAT, thanks to TDD. BP paid them to stay on for the UAT period, which they spent in the pub. If that's not an incentive to learn TDD, what is?" - Explore different languages, tools and paradigms to give you more options and help you solve specific problems throughout your career - Help others - teaching is the best way to learn - Overall takeaway for me is that soft skills are clearly equally as important as hard skills in software engineering Worth a watch. https://lnkd.in/e8bau4X9

15

1 Comment

Your dev team is under resourced Spoiler - it always will be Don't get trapped thinking if you just had two more (or fifty more) devs you'd be able to work through the backlog and get ahead. The problem is that teams try and filter and prioritise *down stream* on outputs. 100's of outputs. Try filtering and prioritising *up stream* on strategic outcomes that matter to the business (and across the business).

11

9 Comments

A colleague used the phrase "hero developer" during a very insightful conversation yesterday. I thought it was a very useful phrase to describe a type of behaviour you want to avoid, whatever your line of business. When you behave like a hero developer, or a hero anything, "you become a quick thinker, someone who wants to solve problems quickly and hack a solution on the spot. Quick thinking gives you a feeling of satisfaction and competency but is generally undesirable. It traps you into biases instead of making you take the time to really analyze problems and come up with the right solutions. You become driven by ego, thinking that you are indispensable. You undervalue the contributions of your fellow teammates and could try to undermine their position. In your mind your teammates are ok as long as they see that you are the most important person on the team. You start centralizing all decisions effectively becoming a bottleneck for your organization." See this post by Luis Guerrero for more insights on how to avoid becoming a hero: https://lnkd.in/eh455cnP #herodeveloper #teamspirit #teamwork

14

Understanding Promises in JavaScript I'm currently exploring the ins and outs of UXPScript in InDesign and Photoshop. There are lots of interesting differences between UXPScript and UXP in both apps; I'll be able to write some interesting articles once I come out at the other end. While doing this work, I am getting quite intimate with Promise, async/await, and it finally dawned on my what annoys me about Promises. I figured out how to resolve that issue. If Promises rub you the wrong way, more info here: https://lnkd.in/gBSBhCjn

9

1 Comment

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

Frontend Developers, thoughts on Svelte? How does it compare to React? Is this a trend or can you see it becoming a leading JS framework? Keen to hear your thoughts. #Svelte #React #Frontend #technologies #javascript

26

43 Comments

I can’t find it now but our team not long ago had a good laugh at a cartoon panel about a software engineer so exasperated at some syntax heavy quasi-code (Terraform, Webpack, Redux?), they quit and took up wood carving. It was our little joke in the Slacks for a minute. Now that the universe has blessed us with an opportunity for reflection (mass lay-offs), we might revisit that theme a bit more seriously. What does a set of wood chisels cost, anyway? I have been consistently surprised, over a couple decades of interviewing software engineering candidates, at how many are unable to demonstrate real interest in the field. Oh sure, there are platitudes; there’s the performative stuff that is the lifeblood of LinkedIn. But there’s less evidence of internally motivated, quiet, continuous self-improvement. What (software engineering things) did you do in the months since you left your last job? What new things are you currently exploring in the field? If the answer is “nothing,” congratulations, you sound like a normal person. But maybe it also means this is an opportunity to realign if not pivot to find what does spark curiosity for you, what you would love exploring. Maybe more UX programming; or more algorithmic. Few things will make your next job more enjoyable than having enthusiasm for the work.

19

3 Comments

Should every #juniordeveloper focus on the number of connections they have on LinkedIn? This was the debate from last nights workshop. What do you think? Is this the networking strategy you are employing? Does it work? Is it worth it? Fyi, there are 2x workshops for #developers on my course. Visit the Crushing Digital website for more details.

29

21 Comments

Why I don’t care about hacker culture - and you don’t have to either. I’m not interested in reading hacker news 🤷‍♂️ It’s the go to place for tech folks to see the latest news; any halfway decent techie *should* find it interesting. But the stuff that gets upvoted just does not interest me. It’s exhausting pretending that it does. 🛠 My first instinct when handed a shiny new tool is not to try to break it. I didn’t grow up taking apart clocks or VHS players - which seems to be the origin story of every great technologist I hear about. 🥰 And when I’m not working, I want to spend my time out with friends - not making a compiler for an obscure programming language 5% faster. What I want to remind people of, is that it’s only for a recent stretch of time that hacker culture has been the prevailing narrative of what being a techie looks like. 🍎 Previously it was the well off and well educated - considered cerebral (which included queer people and women - see Alan Turing and Ada Lovelace) 🚀 Then it was women ‘calculators’ - largely African American women - doing the work to win the space race (see the book/film Hidden Figures) 🖥 Only really when people got their own home computers did the hacker culture come about and dominate the narrative of what it is to be a coder/techie. And a lot of great things come from hacker culture - bug bounties, lowering the barrier to entry of very well paid jobs, the championing of progress over perfection. But the point I want to make is that if you don’t resonate with it, or it straight up bores you, there’s still a place in Tech for you - and your disinterest in it doesn’t bear any weight on how good a technologist you are. 🌟Go find what does interest you and become great at it. It’s out there. Just maybe not on HackerNews…

24

7 Comments

Aside from automation skills that seem to sought after by most within QA + the ever evolving topic around AI, there's plenty of other ways of working/testing techniques that I hear mentioned consistently. - TDD, BDD, shift left, contract testing - to name a few.. Considering we're in a time that is so, so competitive - the last thing QA/QE people want, is to be working in a way that isn't sought after when they look for a change. If you were a junior starting out in your QA journey - what are the techniques/methodologies you'd focus on most? #QA #QualityEngineering

20

15 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

I've started a long-deferred read through of Team Topologies, which speaks to some of the problems I was talking about recently around the ways "utopian" software development maxims can fail when they encounter the "topos" of an organisation's incentive and communicational structure. There's a thought-provoking section on John Sweller's 1988 breakdown of "cognitive load" into three categories ("intrinsic", "extraneous", "germane"). The thought it provoked in me was that I tend to disregard the burden of the "intrinsic" when looking for ways to reduce "extraneous" load (ways a codebase and development environment distracts me with boilerplate and arbitrary irregularity) and gain traction over "germane" problems (those particular to the domain we're working in). For me, leveraging advanced language features to eliminate boilerplate and build out a little embedded DSL that can express the problems I care about is an obvious win - I often refer to Paul Graham's maxim that you should first create the language you want to solve your problem in, then solve your problem in it. The problem with this is that it can shift extraneous load into intrinsic load, by requiring programmers who were comfortable with repetitive constructs using basic language features to familiarise themselves with much more advanced features (and the DSL's idiomatic usage of them) for the sake of eliminating what may seem to them to be quite harmless repetition. This suits me personally, because I like having an advanced model of a programming language in my head and using it creatively, but one isn't accounting properly for the distribution of cognitive load if one doesn't also take "intrinsic" load into account. I think of Golang as an intentionally low-intrinsic-load language - it has a small kernel of features, and is structured in a way that discourages higher-order abstraction over those features. If in doubt, write another for-loop! By comparison, I remember Scala adoption at TIM Group being an intensely painful experience for some of my colleagues, because it introduced so many constructs and type-level features that could be used in so many colourful ways. While I was elated by its endless opportunities for minimising extraneous load, they felt the burden of ballooning intrinsic load, and the frustration of being temporarily deskilled by the change of fundamental environment. The real art is to leverage small changes of technique and perspective, that will fit comfortably in everybody's head, to chisel away at extraneous load, until they feel that the nuts-and-bolts of their tasks are simpler than they have ever been.

10

NestJS - an increasing amount of companies are asking for experience in this. Surprisingly, a number of developers I've spoken to weren't aware of it! This is what I've learned this week from speaking to a number of experienced developers that are using it in production: ✅Promotes a modular architecture, making it easier to manage and scale large applications ✅Built with Typescript, so results in more robust and maintainable code provides a powerful dependency injection (DI) system out-of-the-box, ✅Provides seamless integration with microservices architecture and GraphQL ✅Built-in support for middleware, making it easy to handle cross-cutting concerns like logging, authentication, and error handling ❌ Steep learning curve, especially for those who aren't familiar with TypeScript or Angular concepts ❌ Requires writing more boilerplate code compared to other minimalistic frameworks ❌ For small projects or simple APIs, the additional features and complexity of NestJS might be overkill, making simpler frameworks like Express.js more suitable. What's your experience been of NestJS? Enjoying using it or keen to learn it? Drop me a DM or comment 👇

7

2 Comments

Jira ticket feature request: Tip option to get a bonus when it gets to “Done-Done” For most part, I live by the abolish tip principle. Dont tip. Dont get people reliant on tip. Get the businesses to pay employees fair livable wages. However, if it’s not going to go away anytime soon, can I might as well get tips for my work completion? If my ticket gets verified and get set to Done, my manager or whomever can click a button to give me $ or tiny % equivalent of the project’s value as tip 🤷‍♂️ If I, as a typical consumer have to tip for food on going out on a daily basis, perhaps Im willing to let it be justified if I get a tip as well so it more-or-less hits a zero-sum in my accounting books. At least this way, it all eventually trickles down from corporations back to the hand of the end consumers… Thoughts??

2

Not a Tech Guru but Need to Hire Top Developers? Here’s What I’ve Learned from Hundreds of Interviews... I know the feeling—interviewing software developers when you don’t speak “code” can feel like trying to read a foreign script. But let me tell you: YOU DON'T NEED TO BE A TECH EXPERT TO SPOT AMAZING TALENT. It’s all about digging deeper and understanding how they think. 1. Stop Getting Hung Up on Tech Stacks: I can’t tell you how often I hear, “Oh, you’re a React developer? Sorry, we need Angular.” Really?! If someone’s a pro with React, they can pick up Angular in no time. It’s like saying, “You know how to drive a Ford? Sorry, we only hire people who drive Toyotas.” 😂 Skills are transferable if the person has the drive to learn! 2. Understand Their Problem-Solving Mindset: I always ask candidates to walk me through a complex problem they’ve tackled. If they can explain it in simple terms and show excitement while doing it, that’s a major win. Great developers are also great at explaining things clearly. 3. Focus on Thought Process Over Syntax: I’m not here to critique their code line by line (I can't anyway 😅) . What I care about is why they made certain choices. Are they thinking ahead? Are they considering the end-user? Are they predicting future challenges? That’s where the real value is. 4. Passion Beats Pedigree EVERY Time: I’ve seen developers from non-traditional backgrounds CRUSH it. It’s not about where they studied; it’s about the side projects they’ve built, the new languages they’ve learned on their own, and the communities they contribute to. Hustle > Resume. 5. Culture Fit is EVERYTHING: Skills can be learned, but fitting in with your team’s values? That’s the game-changer. I always ask myself: Would I want to work with this person every day? That’s a big clue. 6. Ask “Why?” Until They Drop Some Real Gems: I keep digging. “Why’d you choose that framework?” “Why take this approach?” “Why are you in this game?” The best talent loves these questions and gives you insights you didn’t even know you needed. In my opinion? Don’t get caught up in the tech details if that’s not your world. Stay curious, keep it simple, and remember: it’s the HUMAN behind the code that matters most. 🚀 #Recruitment #Talent #NonStopTalent #Interviewskills #Softwaredeveloper #hiring

8

5 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