Jason Swett

I once asked a lead engineer on Angular: Which is better: Angular or React? His response: "Both require good engineering to be effective." So, my developer friends, consider this a reminder that "frameworks" like Diátaxis are fine, but they still require good engineering--such as UX, information architecture, style, maintenance processes, and so on--to create great documentation experiences for your customers. Alas, the framework alone isn't enough.

35

7 Comments

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

If culture fit isn't the most important aspect of adding another developer to your team I know you don't ship much. I follow so many small companies that out deliver large ones it's crazy. 3- 10 person teams, ship ship ship ship ship...Why? The mission is ____ing LOCKED in, everyone is on same page from character to keyboard. Let me give y'all hiring managers a tip. When you have those two candidates, one has ALL the tools technically but you vibe better with the other who wants the gig more? Hire the latter, train 'em up. That 4 week ramp up they need on 'X' will be well worth it long term, 100%. #softwarejobs #java #javascript #typescript #react #reactnative #vue #angular #svelte #astroJS #htmx #go #golang #rust #ruby #rubyonrails #scala #kotlin #closure #haskell #elixir #csharp #aws #azure #ai #aiml #tensorflow #python

7

3 Comments

Shielding your team from organizational chaos 🛡️ If you're a leader in software development, you know how crazy things can get. Priorities change on a dime. Deadlines are always looming, and it feels like everyone's on a different page. It's your job to protect your team from all that noise. Here are five strategies I've used: Filter the information. Only pass on what your team needs to know. Set boundaries. Learn to push back on unreasonable demands. Politely, of course. Be the buffer. Take on some administrative junk so your team can focus. Translate the chaos. Turn vague company goals into clear action items. Foster adaptability. Agile practices can help your team handle change better. It's a tricky balance, I know - you want to shield your team but not keep them totally in the dark. But fair warning, it's not always easy. You need to be assertive, flexible, and willing to absorb a lot of the stress yourself. I'm curious to hear from other leaders: what's your go-to strategy for shielding your team from the chaos? #softwaredevelopment #leadership #teammanagement #organizationalchaos

5

2 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

Anyone have experience transitioning from low code/no code development positions to code heavy ones? I recently was speaking to a colleague who was wanting to get into a more engineering focused role, but only had professional experience operating internal no code/low code software solutions. He asked what he could do to transition to a more programming heavy role and whether his experience wouldn’t count and he’d have to take a pay cut. Anyone have experience making the transition? What was it like and what advice would you give? #LowCodeToHighCode #Advice

5

8 Comments

I see lots of posts trying to define what makes a senior developer. Lots of good points contained therein. I think it boils down to 3, no 4, abilities, though: 1. The ability to keep (or make) things simple. 2. The ability to have the most (positive) business impact with the least amount of coding. 3. The ability to communicate. 4. The ability to mentor, directly or indirectly. (Thanks to George Old, who mentored me back when we were both with Salmon, for prompting me to add this to the list!)

3

3 Comments

In over 20 years and many companies (check my profile!) of doing this, I’ve never found that there is a single “right” way of doing things. Some companies are very risk tolerant. Some are very risk averse. Some demand clean, supportable code at all times. Some just need to get it shipped as soon as possible. If you’ve only worked one or two places, you may think that the way they do things is the right way. That’s a jr dev mentality. Be open to the idea that there may be a sound reason for doing things a different way.

5

I think it comes down to two things (1) it’s not enough to make businesses go faster, but rather make them move in the right direction (fast is nice too). (2) there is no evidence that Improving developer experience is necessary or sufficient to do (1) in a large fraction of cases. I don’t think this is a positioning problem - it’s more like a category error. #devex #flow #valuestreammanagement

5

6 Comments

Even /if/ "A.I." coding assistants improved productivity of dev *teams* - and that's a big "if" (the last 2 years' DORA reports suggest they don't) - the history of productivity-improving dev tools has consistently been one of them creating demand for *more* software and *more* developers. If you're not hiring and nurturing entry-level developers, you'll probably find yourselves on the wrong side of history. Competitors who did will stroll past you while you're struggling to hire from a greatly reduced pool of talent. That's the FOMO you should be worrying about. LLMs are a dead end. They're already played-out tech.

130

82 Comments

"Never assume - it makes an ass of u and me". Except when estimating of course. "How long will it take?" has got to be the most annoying question anyone in software development can be asked. Totally get why. There are always tons of variables, especially at the beginning. If someone wants solid timelines, they might not really get how software dev works. But if you can't throw out an estimate with some clear hypotheses in place, you might not get how business works either. Trite though it is, "time is money" and "money doesn't grow on trees". So yeah, it's fair to estimate, but make sure you’ve got those assumptions clear. Assumptions are a big deal in any plan. Ignoring them is why plans fall apart. Look after your assumptions, or you might end up feeling like a bit of a donkey🐴

14

My quick tip if you're interviewing for a CTO role: If you'll be the ONLY engineer on the team... It's not a CTO position. 😜

94

49 Comments

Are you a tech-pert? A technical expert? I've worked with so many talented engineers, developers, and technical specialists who can solve incredibly complex problems – but struggle to explain their work in a way other people can connect with. The most successful tech professionals aren't just technically brilliant. They're also skilled communicators. On January 13th, 2025, I'm running a masterclass specifically designed for technical professionals who want to: 🎤 Communicate complex ideas simply 💡 Build confidence in presentations 🤝 Connect with non-technical stakeholders 📈 Accelerate their career progression Limited spots available. First 10 sign-ups get a bonus 121 30 minute coaching session. Who's ready to transform their communication? #TechCommunication #ProfessionalDevelopment #CareerGrowth

13

8 Comments

Jr. Devs, You need to start thinking outside the box when it comes to your career. I was talking to a friend of mine yesterday and they were telling me about a small business their children (12 and under) had started. I won’t reveal what it is to protect their small advantage. :) But basically, it's providing a simple service that takes very little time for very little cost. It's offering a convenience. Anyway, as he was telling me about it, it was so simple, so obvious, but something I would have never thought of on my own. I’m not really an idea person. I need something to start with, a clear problem to solve. I often need a pre-defined path to follow. Many Jr. Devs need to be less like me, trying to follow the pre-defined path, and more like my friend, looking for things other people might be missing, opportunities no one may notice. Think about ways you could implement what you are learning to help individuals, small businesses, local governments… virtually anyone; to fix a problem, meet a need, or simply make someone’s life easier in areas they may not have thought of themselves. The traditional route into development is clogged right now, so perhaps it’s time to look around and see opportunities from a different perspective. Find a non-traditional route to begin using your skills in a career that might look a little different from everyone else. Who knows, you just might stumble on the next Uber or Airbnb or maybe you just build a great list of clients who need simple work from a trustworthy developer. Take a fresh look at the problem and find a creative solution. #juniordeveloper #mentoring

14

1 Comment

The horror messages I get from #DevRel practitioners and other leaders still blow my mind. Biz leaders telling them to do this, wait, let’s do that. Oh now let’s cancel that and do something else. Developers require time investment. You can’t launch a program today and dump it in a few weeks or a few months because you don’t think it’s working. It’s working, it just needs TIME. Devs need time to decide if you’re trustworthy. Plus, their leaders are clearly throwing darts at a blank wall. I much prefer to throw darts at a dartboard with a clear center target 🎯

63

5 Comments

You can't make anyone do anything they don't want to do. If you find yourself with a team that isn't shipping fast enough, you can't use tactics to "increase the sense of urgency". You need strategy. And that's a problem for the Engineering Manager, not the individual contributor. Certainly, allowing developers to be co-owners of a project is best practice, but that only works if it's actually true. That is, if a developer suggests a better way and you ignore it, or a VP 2 steps above shuts it down, then the team is going to learn very fast to keep their heads down. You need buy-in from leadership. In other words, if you fake it, your people aren't stupid. They may placate you, but they'll know. The gaming industry is still finding this out... And another nit. If a developer commits to a timeline that is unrealistic the first time, oh well, it happens. But if this keeps happening, then what are you as an Engineering Manager doing about it? Releases are often a point of resource contention. If you're running into situations where you can't release because of an individual bottleneck, it usually points to a process issue that you need to fix, instead of blaming devs for missing deadlines that are hard to predict.

1

Again, do not get trapped by the mindset of "I've not seen it, so it doesn't exist." I don't believe I'm misrepresenting Jon Bach's position when I say he thinks developers cannot deliver quality unless someone is testing for them. I'm sure he'll correct me if I'm wrong. Today he told me this: "maybe you can get average players to play together in a way that leads to wins (e.g. better quality and risk mitigation with everyone being equally replaceable at any time) but in my experience, that isn't reality.” He may have no experience trying to solve that problem. I've several years of experience working on that exact problem. The team I was given to pilot CD for the first time at Walmart was not high-performing. In fact, I'd consider it below average. Solving the problem of "how do we deploy to production multiple times per day?" fixed that. Later, when I was given the job of helping other teams figure out CD, it improved those teams too. When a team we worked with had testers who, as Jon advocates for, took the testing load from the developers, we had to redirect them to become quality champions instead of testing because enabling learned helplessness blocks improvement. Besides, you can't do CD with a handoff for testing. In the end, the teams delivered better, the developers were happier, and the testers felt more valued because their work was more meaningful. Perhaps the narrative of developers needing testers to test for them is based on people solving the wrong problems or never being exposed to what "good" looks like.

58

112 Comments