DEV Community: Sam Jarman 👨🏼‍💻

LLM Use for Junior Developers: A Manager’s Perspective

Sam Jarman 👨🏼‍💻 — Tue, 27 May 2025 09:48:07 +0000

I’ve reached that point in my career where I’m mostly done learning to code. (Well, mostly.) I’m comfortable enough with languages and systems that when I ask an LLM to spit out some code, I can eyeball it, verify it’s solid, and submit it confidently. I also tend to think more about large-scale designs, so getting the LLM to handle the “grunt work” of writing boilerplate or wiring up APIs feels like outsourcing to a virtual assistant. It’s nice.

But for juniors? It’s a different story.

Why Juniors Still Need to Learn the Basics (Even if They Want to Skip It)

Junior devs are still wrestling with fundamentals that you really can’t shortcut:

The syntax of their language.
The idioms — eg what “good” TypeScript looks like vs. JavaScript with “any” sprinkled all through it.
How to write solid tests — because coverage numbers don’t count if they don’t catch bugs.
Writing clean, maintainable code — low complexity, good structure, SOLID principles, composability.

This learning grind is part of becoming a great developer. Relying too early on LLMs to just “write the code” is like trying to learn to swim by floating on a lilo. Sure, you’re in the water, but you’re not going anywhere fast.

Using LLMs as Coaches, Not Crutches

That said, LLMs are fantastic when juniors use them as coaches. When a question hits the common-but-confusing realm. Concepts like caching patterns, AWS IAM policies, networking basics – LLMs can explain things clearly and patiently. It’s like having a knowledgeable buddy who never gets tired or annoyed.

They can also act as a first-pass code reviewer , pointing out potential flaws. But remember, LLMs want to please. They might not argue or defend their points rigorously. Juniors need to push back, reason through suggestions, and decide what actually makes sense.

Practice & Exploration with LLMs

LLMs are way more than just answer machines — they’re awesome sparring partners for active learning:

Stuck on a coding challenge? Ask for hints or step-by-step walkthroughs instead of the whole answer.
Looking for side project ideas to explore new tech? LLMs can tailor suggestions to your level and interests.
Need to talk through your thought process? Use LLMs as a virtual pair programmer to brainstorm, debug, or plan designs.

Turn LLMs into learning tools — not just code generators.

Documentation: Learning to Communicate, Not Just Write

Documentation is a skill juniors must build themselves — it’s how you organize your thoughts and communicate your work.

Here’s a better use for LLMs: communication coaches. Draft your docs or explanations yourself, then ask the LLM to help rewrite for different audiences — fellow devs, PMs, or even non-technical folks. Practice simplifying complex concepts without dumbing them down too much.

LLMs can also polish commit messages, pull request descriptions, or status updates — helping juniors learn the tone and clarity good communication needs.

Legacy Code: More Than Just Lines of Mystery

Legacy code is the ultimate challenge. Sure, LLMs can explain snippets or spot obvious problems, but remember: legacy code isn’t just “bad” because it’s old. It’s often a product of history:

Decisions made under tight deadlines
Tradeoffs forced by limited resources
Team and company constraints that no longer apply (or maybe still do)

An LLM won’t know this story. Real understanding comes from slogging through, reading docs (if you can find them), asking teammates, and connecting dots.

Use LLMs as a starting point — a flashlight in the dark — but be ready to do the hard work.

Accountability Reminder: Own Your Code, Even if AI Helped

If you’re submitting code generated by an LLM, you are the one putting your name on it. You need to be able to explain, defend, and take responsibility for it.

No “Oops, CoPilot wrote that and I didn’t check.” That’s not how professional development works. Be accountable. It’s your name on the commit.

Summary: Use LLMs Wisely, and Remember It’s a Journey

LLMs are powerful tools that juniors can use to accelerate learning — as coaches, practice partners, and communication aids. But they aren’t a shortcut through the fundamentals. Learning to code well means practicing syntax, writing tests, understanding good design, and grappling with legacy systems.

Your relationship with LLMs will evolve as you grow. They’ll get smarter, you’ll get smarter, and the ways you use them will change — and that’s totally okay. Think of them as part of your toolkit, not a replacement for your brain.

Use them to learn, not just to do.

Being Effective Under Pressure

Sam Jarman 👨🏼‍💻 — Thu, 28 Nov 2024 08:51:57 +0000

Working under pressure is an inevitable part of life. Even in the best run company, pressure will be on you at some point. It could come from deadlines, customer issues or even your personal life. It'll just happen. Sorry.

However, working under pressure is hard, and I've picked up some skills in doing so over the years and I would like to share them with you today.

Don't Rush

The common trap we fall into when working under pressure is to speed up. But too often we speed up too much and get into rushing territory. Working faster under pressure is important, crucial even, but working faster than you can to deliver with standards is a terrible, terrible idea.

So slow down, take a breath, try to keep calm and keep level-headed. This takes discipline, dedication and practice. Every time I find myself rushing, I take a break to reset and break the cycle.

Be Data Driven

The next trap I see folks fall into when troubleshooting under pressure, such as during an outage is they ignore the clues that are trying to help them. They'll not read error messages properly, they'll skip straight to previous solutions, such as restarting a database unnecessarily when that component is unrelated to the issue. This just wastes time and proves nothing. Work logically through the system that is being debugged. You can read more in my blog post about how to troubleshoot any problem here. In a recent issue, I rushed to restart a VM assuming that the ol' 'turn it off and on again' would fix it, but alas it did not, and it didn't really help. Of course, the service logs had the real problem.

Learn New Things

Another thing people tend to do is think to themselves, "I only have my current skills to do this job; I don’t have time to learn something new." This might seem true at first glance, but it’s not—especially today. With tools like LLMs and GPTs, it’s never been easier to get a quick lesson on something unfamiliar. By learning more, you gain a new perspective on the problem, which may unlock the solution.

Recently, I faced an issue that required me to brush up on Kafka—a technology I hadn’t touched in a while. With the help of an LLM, I quickly rebuilt my mental model, learned a few key CLI commands, and applied them to troubleshoot the issue and I could rule out lagging consumers and misconfigured topic partitions. That new perspective was exactly what I needed to move forward.

Go Down a Level

As part of troubleshooting under pressure, a rushing person often sticks to the surface or around the edges, avoiding a deeper dive into logs or databases. I’ve done this myself—hoping the answer would be on the surface and avoiding the effort of looking under the hood. But when the surface doesn’t yield answers, diving deeper is essential.

In both the examples I’ve shared, the real solutions came from going beyond surface-level symptoms. The earlier I realize this, the faster I can solve the problem—and the better prepared I’ll be for similar challenges in the future.

While diving deeper into technical details often reveals the solution, your team’s communication and collaboration under pressure are just as important.

Stay Humble and Honest

When the pressure is on, it’s easy to panic and feel like you need to have all the answers. But trying to bluff your way through a situation, especially when you don’t fully understand it, can waste valuable time and frustrate your team.

I’ve worked with people who, while well-meaning, clearly didn’t understand the terminology or concepts they were using. Their intention was to help, but their lack of clarity made it harder to get to the root of the issue.

Instead, it’s far more effective to be humble and honest. Say things like, “I’m not too sure what I’m asking here, but…” or “I’ve been told we need this; I’m not sure what it means, but I’m hoping it makes sense to you.” These statements don’t just save time—they also build trust. Your team will appreciate your authenticity and willingness to collaborate, even under pressure.

Being honest about what you don’t know takes courage, but it allows everyone to focus on solving the problem instead of untangling assumptions. When you stay humble, you create an environment where the team can work together more effectively.

Slow Down to Speed Up

Working under pressure is inevitable, but it doesn't have to hinder your performance. By slowing down, you allow yourself to think more clearly and make better decisions. Stay data-driven by paying attention to the clues and information at hand. Embrace learning new things—even under tight deadlines—as it can provide fresh perspectives and solutions. Don’t hesitate to delve deeper into the issues rather than skimming the surface.

Just as importantly, stay humble and honest. When you admit what you don’t know and ask for help, you foster trust and collaboration, making it easier to solve problems effectively. Pretending to know something you don’t wastes time and energy—yours and your team’s. Instead, focus on clear communication and authenticity, even when the pressure is on.

Remember, the key is to slow down to speed up. When you take the time to approach problems methodically, you often find more efficient paths to your goals. So next time you feel the pressure mounting, take a breath, stay calm, and apply these strategies to turn stress into success. By doing so, you not only become more effective under pressure but also build trust, resilience, and confidence in yourself and your team. And above all, don’t be the person who says, “I don’t have time to go faster.”

Working Faster as a Developer

Sam Jarman 👨🏼‍💻 — Sat, 10 Aug 2024 06:37:16 +0000

There was a time when I believed that becoming a better developer was all about learning more, knowing more, and mastering new languages. But then I realised, it’s not just about being better—it’s about being faster. Fast enough to impress, delight, and sometimes even save the day. Today I want to talk a little bit about working faster as a developer.

Why do you want to move fast?

The faster you work, the more experience you get in the same amount of time. As I’ve blogged about before, experience density is incredibly important for getting ahead. Secondly, the faster you go, the faster your customers get the value you’re creating, and this is particularly important in start ups and small businesses. Finally, the time I think its most valuable to have these skills is when things are going wrong. Mastering the skills to code, troubleshoot, and work faster is crucial during downtime issues, critical bugs or urgent matters can make you the hero of the office and hugely valuable to your company.

What working fast doesn’t mean

I don’t want you to think I’m advocating for rushing in this blog post. Working fast does not mean rushing. It does not mean putting out lower quality work. It does not mean skipping steps. And finally it does not mean putting out a worse product your customers hate. Working fast is working to your usual high standards but simply in a shorter time frame. With conscious effort and practice, you can make it happen.

It’s all about habits

If there’s one thing that I’ve found to be scarily true, it’s that habits cumulate. Good habits speed you up, and when they cumulate, you can go faster and faster. But the opposite is also true, bad habits can slow you down, and when you have many bad habits, you can approach a glacial pace. This post is about habits. Habits you should work on over and over again, collecting more and more as you cumulate to approach the most efficient version of yourself.

Why?

You might think “Why should I work faster?It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime; so where's the motivation?” This is true. I’m not advocating you work at 120% every day at the office only to burn out to a crisp in weeks. And I certainly don’t advocate it if you feel you won’t be recognised for it. Good companies with good managers will recognise it (bonuses etc) and these companies will open doors faster for you than they would for others. And of course finally, you have your own ethics, values and craftsmanship to consider when deciding how much effort to put in. Do what feels best for you.

Disclaimer

I’m not perfect. I don’t follow all these tips myself either 100% of the time, and I’m not claiming to be faster than you or my team. Finally, this list of tips is not al the tips out there. Please keep looking for them and collecting them. And I’d love if you found some that worked for you and you let me know. Perhaps this list can keep growing. Let’s get into the tips.

1. Develop a Sense of Urgency

This idea is borrowed from the retail space, where work happens quickly in order to keep a store running smoothly. If you want to move fast, you have to want to move fast. It’s not about rushing or cutting corners, but about cultivating a mindset where you’re driven to deliver value swiftly. A sense of urgency isn’t something that just happens — you have to nurture it. Start now.

2. Copy and Paste Effectively

Let’s be real: copying and pasting is a developer’s best friend when used wisely. But the key is knowing when to start and when to stop. Don’t just blindly copy code; understand it, and make sure it fits your current context. Sometimes, it’s better to copy the idea rather than the actual code. Ask yourself: “Surely another team has solved this” (and go look at their code) or “Surely I’m not the first person to do this” (and go to Google/StackOverflow/CoPilot). On the team idea - its a good idea to keep a bit of a mental map of what other projects your team or wider team are working on, to give you a some places to check. Paying attention to work going on around you pays off in all sorts of ways, but this is one I’ve enjoyed a lot. Start unmuting those slack channels now.

3. Master Your Language

Whether it’s TypeScript, Python, or any other language, having the syntax in your muscle memory is crucial. Practice regularly, beyond just your backlog tasks, to make sure you’re always sharp. Finding solutions for tricky parts is just as important as mastering the language itself. Go write a lines of code for practice.

4. Use IDE Extensions to Your Advantage

Your IDE is a powerful tool, but it’s only as good as the extensions you use. Regularly explore new extensions and ask colleagues for recommendations. For instance, tools like JSON to TS or Toggle Case can save you loads of time. Share the ones you find, and even set them up in your code templates so fellow devs get recommended they install them. Also, if you see a colleague do something when you’re pairing that looked fast/magical - stop and ask them how they did that– you want that power too! Ask your colleagues for their recommendations now.

5. Use Terminal Aliases and Dotfiles

Long commands slowing you down? Create aliases. For example, gco for git checkout or gcob for git checkout -b. These small shortcuts can add up over time. Check in your dotfiles and use them everywhere you go. Even think about creating a standard set for your team. Get yours into Github now.

6. Search Documentation Smartly

When you’re deep in the weeds, knowing how to efficiently search through documentation can be a game changer. Use shortcuts like Command + F in Chrome to find what you need quickly. However, when you’re new to something, it pays to slow down and read the full documentation to get a comprehensive understanding. The better mental model you have for what should be in some documentation is the better – as it makes it easier to find stuff. Finally, you’ll realise there’s a few popular tools for documentation out there that a lot of OSS uses and so eventually you’ll build some skills on how to find the search bar, toggle dark mode, even if you’ve never been to that particular website before.

The other part of this tip is knowing how to get do the documentation of your tool fast. Command clicking on method definitions, or googling certain terms, or having it bookmarked. Work on reducing the lag time from deciding you need to look something up to being in the right place and reading it. You should also be very effective in documentation you use regularly.

7. Understand the Big Picture

Stepping back to understand the broader concepts behind what you’re doing can speed you up in the long run. For example, don’t just learn how to use AWS SQS; understand the concept of queues, messages, retries, visibility, etc so when you encounter similar tools like Azure Queue Storage, you can adapt quickly. Mapping existing knowledge onto new things is only as good as the existing knowledge - so keep building it. Reflect a lot on your work. Reflect, reflect, reflect. Lock in that learning. It will cumulate. Remember my saying: Work + Reflection = experience. The more experience you have, the faster you go.

8. Be an Expert in Your Tools

Spend hours a day in tools like VS Code, AWS, or GitHub? Make sure you know them inside and out. Learn the shortcuts, understand the error logs, and know when to restart your tools. Mastering this expertise shaves precious seconds off your workflow. Let’s say you’re a VS Code User, you’re in it eight hours a day. Do you know the shortcuts? Do you know multi-cursor editing? Do you know how to see logs for extensions? Do you know when your extensions aren’t kicking in? Do you know when it’s time to give up and restart VS Code? If you’re using something for 8 hours a day, there’s really no excuse to not know your tools inside and out. This is a sign of any good craftsman. Watch some tips and tricks videos on your IDE today.

9. Shorten Your Debug Loop

The debug loop is the time between writing code and seeing if it works. Aim to shorten this as much as possible—ideally to just a few seconds. Setting up a quick debugging environment or even creating a small test project can pay off in the long run. Learning how to enable debugging (or at least logging) in your tooling is also hugely important, as it will save you time and time again. Start thinking of ways to shorten your loop on your current task.

10. Leave And Read The Clues

Code changes over time. Additions, subtractions and substitutions. There are small but powwerful things you can do to help the next person change the codebase (which will likely be you). Comments, README files, and a well-structured codebase are your future self’s best friends. The more clues you leave, the faster you’ll be able to navigate your code later on. Of course, learning to read the clues is just as important as well - for example, recognising the codebase structure by the patterns it uses, Clean Architecture, Singleton, Serverless. Next time you’re in your codebase - try ‘read the room’ a bit more - what do you notice?

11. Bookmark Everything

Websites, code snippets, curl/postman requests—if it’s useful, bookmark it. This way, you’re never more than a click away from the information you need, or you once had. Both physically bookmark it (in a tool like your browser or snippet library) and mentally bookmark it – so you remember you have it stored. A forgotten bookmark is no use to anyone.

12. Automate Repetitive Tasks

If you find yourself doing the same thing every day, automate it. Whether it’s a bash script or a custom tool, automation can save you hours over time. My teams often build internal CLI tools or script collections, making it easy for everyone to write and share scripts. This is a super powerful way of keeping yourself and others speedy. Pitch this to your team today!

13. Slow Down to Speed Up

Sometimes, the fastest way forward is to slow down and learn something properly. Don’t hack away at things just to get them done—take the time to understand what you’re doing, and you’ll move faster in the long run.

14. Practice Makes Perfect

Side projects, hackathons, or even working on internal tools can give you the extra practice you need to get faster. The more you code, the more efficient you’ll become. It’s cliche, but practice makes perfect. There’s always more stuff to be done, in both side projects and at work, so as your team if you have capacity and want tasks to practice on.

15. Document What You’re Learning

Struggling to learn something? Document it. Writing things down not only helps you retain information better, but it also gives you a reference to look back on later. I might even be doing this right now. By typing out stuff you're struggling with, you will learn it and retain it better. You will find gaps in your knowledge as you try to paint a narrative. Start a blog or a personal diary today.

16. Be Aware of your Surroundings

Its highly likely another developer has solved the same problem you have. Keeping an eye on your teams work channels, emails, sprint reviews, etc will help you learn waht others are doing. Store a mental bank of all of it, so you can go ask people or their code for help. You can do things like searching slack or emails to help you recall. Finally, peers teams to work and ask questions in public forums can benefit everyone, even if it is a little awkward and be embarrassing. It also helps to build a network in your team and company to collect the set of gurus who can help you with various things. And pay that forward - if you become a guru in something, be approachable as well.

17. Ask for Help at the Right Time

Knowing when to ask for help is an art. A skill you will build over your career. Don’t spend hours in the weeds—reach out when you’re stuck. But also recognise when struggling through something on your own will lead to valuable learning, and perhaps make you faster at the future. Keep working on that intuition of when to ask vs when to push through.

18. Lean Into Your Tools

Tools like TypeScript (over JavaScript), Unit test frameworks, linters, formatters can save you so much time. Lean into these tools and understand their features and powers and reap the benefits. Be on the lookout for more tools that you can add to save you time. Ask your more senior developers if they have ideas for tools they think would benefit your team.

19. Stay Busy

Always have more than one task on the go. If you’re blocked on one, even for a few minutes, move to the next. And if you run out of work, don’t wait for the stand-up—reach out to your lead or manager immediately to get more work. There’s always more to do and downtime robs you of experience you could be gaining. After you finish this post, check the backlog for something to do in parallel.

20. Scale Yourself

If you’re creating packages or working on shared code, document it thoroughly. The more you document, the less time you’ll spend answering questions about the work later on. If you contribute 10 internal code packages to your team, but don’t document them – can you imagine how your days will look? You’ll be bogged down answering questions. However a good readme or changelog that does the talking for you can free you up for more interesting things. What is essentially happening here is your past work is working for you without you doing anything. It’s what this blog post is doing for me right now. Saving a 1:1 conversation with every reader. Try this on your next work package.

Bonus: Using AI Coding Tools

I’m in my early days of using AI Coding tools (at home) – Like GitHub CoPilot – so my observations are limited. However I’ve noticed for situations where you would think many other developers have done what you’re about to do, like write a map function or do some bread-and-butter react coding, then AI tooling can quickly generate boilerplate code. However, I’ve wasted plenty of time expecting too much from my AI assistants, so do be careful and take your time to figure out when they work and when they don’t. Also be sure not to rob yourself of a learning opportunity when asking the AI to solve it for you - you may be robbing yourself of future speed.

In the end, moving faster as a developer isn’t about rushing—it’s about building the right habits, using the right tools, and continuously refining your process. Start implementing these tips today, and watch your productivity soar. And remember, the aggregate effect of all these small changes is where the magic happens. You’ve got to want to move fast, and that’s not for everyone, but I recommend it. In the end, moving faster isn’t just about speed—it’s about efficiency, creativity, and staying ahead of the curve. It’s about wanting to be the best you can be, without burning out. Good luck.

Mindsets for using Code Patterns

Sam Jarman 👨🏼‍💻 — Tue, 30 Jul 2024 09:26:21 +0000

Hey there, fellow devs! Today, we’re diving into the world of code patterns, and trust me, it's going to be a fun ride. Whether you're a seasoned coder or just starting out, understanding code patterns can help you write cleaner, more maintainable code. So, let's jump right in!

What are Code Patterns?

Imagine building a house without any blueprint. Chaos, right? Code patterns are like blueprints for your software projects. They provide a structured way to solve common coding problems. Some popular patterns you might have heard of include MVP (Model-View-Presenter), MVVM (Model-View-ViewModel), and Clean Architecture. These patterns usually sit on top of the SOLID principles, which are fundamental to object-oriented programming.

The Origin of Patterns

Code patterns didn't just pop out of nowhere. They’re borrowed from other disciplines like civil engineering. Remember how architects use patterns to design buildings efficiently?

For a practical example, picture in your mind a restaurant that you’ve been to that has outdoor seating. What do you see? Benches? Stools? Heaters? Pillows/blankets? Ordering aparatus? Festoon Lights? These are all implementations of the pattern of “outdoor seating” but of course not every restaurant is the same. That would be weird.

We do the same with software. Learning the context from these original disciplines can make you a better developer.

What's Not a Pattern?

Okay, let's clear some air here. Patterns are not frameworks, packages, or solutions that give you all the code you need. They’re abstract concepts implemented by code. Think of them as guidelines rather than concrete implementations.

The SOLID Principles

SOLID is an acronym for five principles that ensure your code is easy to maintain and extend:

Single Responsibility Principle : A class should have only one reason to change.
Open-Closed Principle : Software entities should be open for extension, but closed for modification.
Liskov Substitution Principle : Subtypes must be substitutable for their base types.
Interface Segregation Principle : Clients should not be forced to depend on interfaces they do not use.
Dependency Inversion Principle : Depend on abstractions, not on concretions.

All good patterns help you implement these SOLID principles. If you haven’t learned them yet, go ahead and do it. Your future self will thank you.

Why Use Patterns?

Patterns make life easier in so many ways:

They provide a recognizable architecture, so new team members can start contributing faster.
Naming conventions and sometimes configuration conventions help maintain consistency.
Good tooling (like Rails’ “generate” function in it’s CLI) can make development smoother.
They help separate concerns, making your codebase more modular and maintainable.

The Big Takeaway

It’s more important to use SOLID principles than to rigidly stick to a pattern. Some developers get so caught up in implementing a pattern that they end up with overcomplicated, hard-to-maintain code. Don’t fall into that trap!

When Patterns Fall Short

Not all codebases are the same. Some are too small or too simple to benefit from heavy patterns. For example, during microservices migrations, you might find some services are too small for a heavy pattern. Always evaluate your need for a pattern and don’t force it.

Conclusion

To wrap things up:

Focus on writing SOLID code. Patterns should serve you, not the other way around.
Evaluate patterns carefully and don’t contort your code to fit a pattern if it doesn’t make sense.
Smaller codebases often need less architecture. You can always refactor later.
If your patterns aren’t working, don’t be afraid to change things up.

Remember, your teammates can help you decide the best approach for your project. So, keep learning, keep coding, and may your code always be clean and maintainable!

Friday Deploys

Sam Jarman 👨🏼‍💻 — Sun, 21 Jul 2024 03:49:22 +0000

Hi everyone! It seems timely, for no particular reason to talk about "Friday Deploys". The conventional wisdom tells us to avoid deploying software on Fridays like the plague. But as with most things, this advice isn't as black and white as it seems.

The Friday Deploy Dilemma

Let's dive into why Friday deploys are generally frowned upon. The biggest concern is the risk of running into issues over the weekend when the team is off duty. Imagine pushing out a release at 2pm on a Friday, only to have a critical error pop up on Saturday. With nobody around to handle the fallout, you're stuck with either a buggy product or a potentially lengthy rollback until Monday.

Time Zones and Their Tricky Impact

But here's where it gets tricky. When we say Friday, whose Friday are we talking about? I'm based in Australia, so a deploy on my Friday could very well be a Thursday for the rest of the world. This could mean that a Friday deploy for me doesn't carry the same risks as it would for someone in, say, the United States.

Who's Using Your Application?

Before you take the "no Friday deploys" advice at face value, consider who uses your application and when. If your user base primarily consists of business customers who clock out by the weekend, then a Friday deploy might not be as risky. After all, any issues that arise would likely come to light on Monday when your team and theirs are back in action.

Conversely, if you're serving a global audience, you're facing a 24/7 operation where time zones can really throw a wrench in the works. In such cases, sticking to a strict deployment schedule that avoids weekends might be more prudent.

Self-Healing Infrastructure: A Game Changer?

Another factor to weigh is your infrastructure's capabilities. If you've got systems in place that can auto-scale or auto-rollback without human intervention, a Friday deploy could be less daunting. With the right setup, you can enjoy your weekend without the looming fear of unexpected usage spikes or bugs.

The Counter Argument: Confidence in Your Software

Now, let's tackle the flip side of the argument. Some might say that if you're hesitant to deploy on Fridays, perhaps you're not confident enough in your software. And there's a grain of truth to that. Using "don't deploy on Fridays" as a crutch can lead to infrequent shipping and a culture of fear around releases.

QA and Continuous Integration: Building Confidence

It's essential to look at how you're testing and integrating your software. A robust QA process and continuous integration can bolster your confidence, ensuring that your software is ready to go live, regardless of the day. If you can't trust your software to work in all the scenarios you've tested, then it might not be ready for prime time on any day of the week.

The Takeaway

As you can see, the issue of Friday deploys isn't cut and dry. While the general wisdom holds true for the most part, it's not a one-size-fits-all rule. The key is to deploy software when you're fully prepared to support it post-launch. That means having the right monitoring in place and being ready to step in if things go south.

If human intervention is crucial for your operations, then indeed, Fridays might not be the best time for a new release. But if your systems can handle things autonomously, there's no reason your customers shouldn't enjoy the benefits of your work up to three days earlier.

I'd love to hear your thoughts on this. Do you stick to the no Friday deploys rule, or do you have a different approach? Let me know in the comments.

Thanks for reading!

Permalink

On Experience

Sam Jarman 👨🏼‍💻 — Sat, 07 Oct 2023 05:49:42 +0000

Today I'd like to share some thoughts on experience.

How do I define experience? What are we getting when we get "experience"? In software engineering, I think of it as building up a mental model of problem and its solution(s). It's building a big bank of lots of problems, their details and then what the specific solution was to those. With this bank, approaching new problems feels easier or even intuitive, as the new problem quickly matches (or at least resembles) a previous problem you've had, and the solution to start trying is the one that worked last time.

In the book Slumdog Millionaire, the main character Ram Mohammed Thomas wins 1 million rupees in a game show through answering 15 questions correctly. Whilst not a genius, its just his luck that the 15 questions line up with 15 experiences from his life. He experiences what most would assume is luck. However, an experienced software engineer, or any professional can feel just as lucky as they come to a problem they've seen before, and solve it swiftly.

So, how do we get there? How do we get lucky?

We often think of and talk about experience in terms of time. Typically in terms of paid, relevant work to one's profession. For example, if you graduated in 2010, have been working since and now its 2023, you've got 13 years of experience.

Measuring by time is objective and cannot be argued with. However, it, in my opinion, is the most naive measurement of experience. Comparing two job candidates, employees or colleagues by it is always a fool's errand. We all intuitively know that is a weak comparison at best. So... what other dimensions are there?

The Dimensions

Density

There's an old phrase - "Its not the years in your life, but the life in your years". I like the phrase. It feels right. I'm sure you'd agree. Perhaps you've had the experience of going to a funeral of an elderly person and they say comments like "they lived a full life, never a dull moment" and the implication is that they filled their years. We accept that a full life is a good one. Hence the phrase.

But I'd like to pinch it and modify it a bit. "Its not the years of experience, but the experience in your years". So this talks to the first dimension, density.

Density of experience matters. There is a notable difference between a developer who has had 10 years at a slow moving company vs a developer who has had 10 years at a faster moving company. They would have simply written more code, solved more problems, shipped more products. Their bank of experience will be bigger, because the work was denser.

Variety

The next dimension is variety. Similar to density, variety of experience can bring value in terms of problem solving. Developers might do this by changing tech stack, industries or companies. They might move from Mobile, to Web to Backend and all the way back again. They might move from start up to agency to corporate to small business. All the variety of problems increases your experience and when you come up against a new problem, the variety you have helps. In fact, I would go as to far as to say as changing jobs, tech stacks or industries would be the easiest way to keep your density high. Variety is a path to density, but not the only one.

Depth

The final dimension in my mental model of experience is depth. Going deep on a problem, is arguably a type of variety but it is a type not a whole lot of people get. When I say deep, I mean deep. Contributing to the framework or language you work with for example. It will take you on journeys that the hello world or the basic bread and butter coding tasks just simply won't. For example, a competent Ruby on Rails developer should be able to make a simple CRUD based server side application and be able to add new routes easily. However, have they understood what is Ruby and what is Rails? Have they contributed to either project? Have they ever made and distributed their own "gem" (a code module)? Going beyond the surface when it comes to software development is a great way to gain more experience that others won't have.

Now what?

So those are some dimensions of experience I believe exist: Density, Variety and Depth. However, these dimensions are incredibly hard to measure, so while you can't prove these aspects of your experience as trivially as time, they do show in day to day work, and so are important to work on.

So how do you get more experience in your years? I'm still figuring this one out myself, but here's some things that have worked for me. I would note that I got lucky, I did the following things in my career out of curiosity and passion, not some well devised plan to gain experience quickly, however, that's what's happened, and I'm so glad.

Changing Tech Stacks

My development career started with using Apple iWeb and tinkering with the exported HTML and CSS. From there, I started to tinker with iOS apps. I put a few on the store before leaving high school, and even did a short internship at an app development agency before university. During my university years, I used other languages as well, and during my internships I used C#.net. Leaving university, I went back to iOS again. That quickly turned into full stack. From there, back to iOS, this time, using Swift instead of Objective-C. From there, off to NodeJS land, which also saw me doing a bit of React. From there, contracting in mainly React. Now I'm back to the backend with Node JS. Seeing all these tech stacks, you start to see some patterns. How they do 3rd party module management, how they do debugging, what IDEs they use, etc. You see the similarities and you see the differences. It builds the bank in an interest way because you see what things in some platforms are inspired by others. For example, CocoaPods, an iOS package manager, is clearly very inspired by Ruby's Pods system. The person(s) who started CocoaPods used their variety of experience to make iOS development better or everyone. What an amazing legacy.

Changing Types of Company

My career has seen me at a few different companies. This sort of variety I was deliberate about. Some boxes I wanted to tick when first starting out was: agency, start up, big business. I'm proud and honoured so say I've ticked those boxes. I also included in there a small business and a multinational business. They're all different in the day to day, and there is lot off not-coding differences to them and you might think the company type is irrelevant to programming, however, the way you solve problems at these various companies is quite different. There are simply different constraints which force you to think, act and code differently. Your bank of experience builds up with the quick way to do something, to the good enough way to the rock-solid way. These experiences are all good to have.

Finding work off-backlog

Regardless of company type, most jobs are basically "here's a todo list, do it". Think Jira/agile. However, in some companies, particularly in slow moving ones, you find yourself blocked or simply not challenged or not busy enough. What I've done is always try to find way to add value to the business while getting some extra coding in. This could be almost anything, but some things that have worked for me are creating component systems, doing some refactoring, creating some internal tooling, creating to some internal code packages, creating coding templates, helping others with their work or doing proof of concepts into new technologies. All of these, if you can also do your 'day job' at the same time, can add density in an organisation that can otherwise not organize that density for you. In such organizations, your learning and growth is on you.

Conferences, Meetups, Talks, The Internet

A nice complement to work, if you have time for it (we don't all have such a privilege...), is using the many many resources out there in the world to build your bank of experiences up. You're doing it right now by reading this blog post. There's SO much out there to learn from. Get along to conferences, meetup or watch the talks online. YouTube has plenty of folks teaching, and hacker news and reddit have plenty to stories to share. In most of these resources, the author is trying to help you gain experience without doing the work they had to do. Its basically free experience. Will it be as good as doing it yourself? No. But its better than nothing.

In Summary

Its your job to get as much experience as you can as you proceed through your career. The more experience, the more success you will have. You need to be mindful when its being organised for you, or if you need to be hungry for it yourself. You need to be deliberate in collecting experiences and try to be efficient with the time you spend doing so. Good luck!

How to Troubleshoot Any Problem

Sam Jarman 👨🏼‍💻 — Sat, 19 Mar 2022 07:13:29 +0000

The career of a software engineer is filled with and perhaps defined by troubleshooting and problem solving. Being an effective troubleshooter can make you an incredible developer, as your team will look to you to solve difficult bugs or fix issues. I believe advanced troubleshooting skills form part of what makes a senior engineer great, but I think you can start working on those skills from day one. Over the years, as I've transitioned to more of what people might call a senior developer, I've picked up more and more tips that work for me when troubleshooting, and in this post I will lay them out for you.

Slow down

A trap that we all fall into from time to time is rushing on a task. Maybe a deadline is approaching or you're feeling behind. Maybe you're an energetic junior and you feel like you have something to prove. (Whatever the reason, we all get into situations where we get stuck, we fall behind, then we rush to catch up but the rushing itself means your logical and methodical mind takes its hands off the wheel and panic has full control. To be fair, we don't do ourselves any favours by calling our work "sprints", when really its more of a speed walk.

I genuinely believe a big skill of a software engineer is staying calm, collected and patient in the middle of a problem. Rushing causes mistakes, you miss things, and you really don't get anywhere any faster. I remember being a junior, and during sprint planning I would be assigned tasks that I didn't know exactly how to do and feeling very uncomfortable about it, a panic set in and I dreaded working on it. Now, years later, I feel much calmer in the face of unknowns. I say things like "I don't know, lets pair on it and figure it out" to colleagues regularly, and I feel much more at ease than those first few years.

So if you find yourself in problem solving mode, breathe, slow down and focus on the task. Usually there isn't a rush, and so use the time you have to work effectively.

Act Logically

This brings me to my second bit of advice - act logically. Software and codebases are systems, and generally speaking most systems have a design to them. Perhaps the code is arranged into components, portions with different responsibilities like managers, controllers, data persistance and view rendering. Looking at a higher level, you might be reasoning about a collection of codebases in a microservices architecture system.

Whatever the system or whatever level you're at, you'll have a unit that has inputs and outputs. When chasing bugs, its good to act logically and rule out areas of the system unit by unit. If the unit you're looking at has correct inputs and outputs, good, move onto the next one. What is this unit talking to and what is talking to it? Follow that chain, working methodically through the system. If you fail to act logically and instead just check the places you're familiar with or think that first might be the issue, you might get stuck pretty quickly, which doesn't help.

Over time in the same system, you'll understand the units more and how they interact. And after a while you'll be able to move quicker ruling out parts when an issue comes up, zeroing in on the location of the issue much faster. The corollary of this is if you want to learn a system fast, then go solve a weird bug in it. It will take you on quite the tour. Generally speaking the more you know about the codebase you spend your days in, the more effective developer you'll be, so don't stick to your bit, have a look around from time to time.

Generate Clues

A huge mindset win for me the last couple of years has been to realise that I'm at a wall and stuck, and asking myself what can I do to give myself another clue. This could be running portions of the code in isolation, logging out values, testing various bits and bobs and generally having a good experiment and explore.

No one action is designed to be the fix, but a result of an action could spark an idea for what to try next. This sort of experimental, exploratory approach to problem solving has been really effective, at least for me. By way of example, I was recently troubleshooting a new colleague's inability to install some internal packages via npm. The error logs weren't particularly helpful to us, but some logs did indicate some of the substeps the npm script was doing. So, I thought perhaps running one of the substeps, a git command, in isolation could give us a clue. Perhaps npm was hiding some output or behaviour from git. We ran git pull on one of the private packages and suddenly we were asked for an SSH passphrase, something that npm had prevented from coming through. A clue! After realising that SSH wasn't quite set up properly and fixing it, npm install succeeded. We didn't know it was SSH from the logs, we just had to try and see. Just explore. Generate clues.

Over time, you build up a sort of clue generating toolbox, this metaphorical toolbox contains all the things you can do to find clues or poke at a system. They range from writing failing tests all the way to log messages to inspecting network traffic.

Trying to list my personal toolbox would be a tricky, as my toolbox is vast and is full of years of experience. Yours is probably bigger than you realise, too. A carpenter who has forgotten about his screwdrivers trying to use a hammer won't be very effective. Being aware of what is in your toolbox and adding to it over time will make you a much more effective developer.

A New Error is Progress

In addition to avoiding rushing, during troubleshooting it can be very easy to only see failure. These depressing thoughts can be distressing. However, there is a sage bit of wisdom / programming meme to call on here: A new error is progress. Similar to finding clues as described above, sometimes you fix something and you see a different error. It's very easy to be upset by this, thinking the issue remains unsolved or you're making it worse. However, and more often than not, some fixes in the software world need multiple actions to resolve. As you solve one thing, the system will produce the next error for you. Be happy! The error is gone! You've finished that bit, but now there is another thing to solve.

I think the subtext of this meme in programmer culture is that problem solving is often more of a battle with yourself and your emotion than the system at hand. I think working on disciplining your emotions when problem solving is incredibly important. You might find yourself getting frustrated, feeling embarrassed, rushing, feeling upset, feeling incompetent, or feeling like an imposter. If this is you, I recommend thoroughly working on controlling these feelings. By knowing yourself and recognizing its happening to you so you can work through it and keep working logically is really important, and a skill you get better at over time. Even many years into my coding life, I still feel these things when I'm really stuck, but I try to snap out of it as soon as I can and stay focussed. It happens to the best of us, and it really is part of the journey of problem solving, and makes the feeling of getting to the solution a lot sweeter.

If you're out of your depth, ask for help

Finally, there will be some problems you're not going to be able to solve on your own. These are generally the problems where you have too many unknowns (either known or unknown) and you aren't able to follow the advice above. You can't move logically through a system, because you don't understand it, or you can't give yourself clues because you don't have enough clue generating techniques in your toolbox for the system at hand. More often than not, this happens to developers who are working on new systems, languages or technologies that they haven't worked before. Hopefully you are in a team setting where someone else, perhaps a longer serving employee or a team member with a different skill set is able to help you, they can point you in the right direction, or remove the fog that is in the way of your path to finding the solution, and you can start to troubleshoot effectively again.

If you're on your own, then I find the way out is to read and read. Go back to the basics, what are the basics of the system, what are the key concepts, and what do I not know about what I'm looking at. I've been in situations trying to debug some code where I've literally googled every line of code or configuration and reading the documentation about it. Somewhere along the way a clue generation idea came along, then a clue and then I was off again. It's definitely slower, but sticking to the tips above got me through. And soon, you may be able to help the next person looking for help.

In summary, here are my tips

Slow down, you could be rushing
Act logically, you could be missing parts of the system to check
If you're at a wall, start exploring and see if you can find any clues
Keep your thoughts positive, any progress is progress even if its not the end
Know when to ask for help

Troubleshooting and problem solving is definitely a skill that builds up over your career, but you must consciously work on it. Watch other developers work, pair with them, ask "how did you think to do that?" or watch them use their clue generating toolbox and add what you see to your own. Finally, these skills aren't just helpful for the day job, they generalize to a lot of problems in life which you could now approach with ease. It might ruin escape rooms though, sorry.

We can only keep learning if we keep teaching (100 Bytes Of Wisdom: Day 72)

Sam Jarman 👨🏼‍💻 — Sun, 17 Oct 2021 04:43:16 +0000

Tech is a field where learning is a constant, however, I'd go further and say that this means you should always be teaching. If you learn something well enough you should be able to teach it. And without folks teaching others, how were you able to learn in the first place? This field benefits so much from an awesome few doing a lot of teaching, and you should be both grateful but also try to do your part, too. Whether it be a full blown blog or even just some one-on-one time with a colleague. For as long as learning will be essential in software, teaching will be, too.

Heads up: As with any terse bit of advice, there will be exceptions of course, and subtleties and nuance that can't possibly be captured in a Byte of Wisdom. This has been what I've experienced, I'd love to hear yours in the comments too!

You can catch up with all the ther bytes at http://bytesofwisdom.com/

Empty String Considered Harmful

Sam Jarman 👨🏼‍💻 — Sun, 10 Oct 2021 02:50:52 +0000

The use of empty strings when used to indicate a null value or lack of value, when the language you're using has a better way to support that will, will lead to bugs and hard to maintain code. With very few exceptions, empty strings should be avoided at all costs.

Several times over my career I have demonstrated the problem of using empty strings to colleagues, so I thought it was about time I write it up for you all to hopefully learn from.

Let's take a simple example. I'm going to use TypeScript for this article, but it's not a typescript article: it applies to any language that has a type system and that type system can express that a value is of type "string" or "undefined"/"null"/"nil"/"optional"/"maybe", etc.

So, let's take a look at a method that will return a name that supports a person having a nickname. Think of Dwayne "THE ROCK" Johnson.

function printName1(firstName: string, lastName: string, nickName: string) {
    return `${firstName} "${nickName.toUpperCase()}" ${lastName}`;
}

For a simple call, this works fine. I can call it like this:

printName1('Dwayne', 'Johnson', 'The Rock')

And I get the output I expect. Dwayne "THE ROCK" Johnson

Now, I want to modify the code to support no nicknames. Not everyone has a nickname, so fair enough.

My first instinct might be to send no middle name.

printName1('Dwayne', 'Johnson')

But then the compiler kicks in, and my IDE tells me that I'm calling with 2 arguments instead of the expected three. Fair enough. But I'm in a hurry and I just need to get this done. So I can just work around this.

printName1('Dwayne', 'Johnson', '')

I don't bother to test it because I know that an empty string won't show anything. I roll it out to production and then my users start to complain.

Suddenly, we're seeing First "" Last in the UI - huh?

Ohhhhh. We didn't check for an empty string. Hmm. Okay then. Well, in this rare and privileged situation, I am both the author of and the consumer of the code. I wish the compiler could tell me to handle it, but alas, it does not, but I am smart and I can fix this.

function printName2(firstName: string, lastName: string, nickName: string) {
    if (nickName.length > 0) {
        return `${firstName} "${nickName.toUpperCase()}" ${lastName}`;
    }
    return `${firstName} ${lastName}`;
}

Good that works now. I've exploited the fact that I am in the lucky position of controlling both the function implementation and the caller of the code.

But what if you're not? Most the time you aren't.

We can do better, and lean on the compiler of our language to help us.

Let's say we instead chose to accurately express the function with more accurate types.

function printName3(firstName: string, lastName: string, nickName?: string) {
    return `${firstName} "${nickName.toUpperCase()}" ${lastName}`;
}

Now we can call it both ways:

printName3('Dwayne', 'Johnson', 'The Rock')
printName3('Dwayne', 'Johnson')

And the compiler doesn't complain like it did the first time. No work arounds, no hacks. Much easier for the caller of the function.

And as the author of the function, we have an easier time too. We're able to communicate, without extra documentation or communication of any kind to the callers (which may be you, future you, a colleague or a person on the other side of the world..) what this method does and expects.

And secondly, as we're writing it, the compiler comes to the party and warns us that we haven't handled the possibility of a missing nickname.

Awesome. We can fix that.

function printName3(firstName: string, lastName: string, nickName?: string) {
    if (nickName) {
        return `${firstName} "${nickName.toUpperCase()}" ${lastName}`;
    }
    return `${firstName} ${lastName}`;
}

The broader point here is that type systems are incredibly powerful and can check a lot of potential logical errors for you. However, it can only help you as much as you help it. By properly expressing to the compiler through the language that this string can be optional, we get the compiler helping us all the way through our code. By inventing our own indicator for optional strings - the empty string - we get no such help, and bugs find their way in very quickly, even with guards such as documentation.

So, this is why I consider empty string harmful in languages that have these features. It indicates a lack of understanding about the language and its ability to help you, the mistranslation of requirements into code and the possibility of future bugs.

However, there are a few exceptions to this rule. Generally these should only occur to the "entry point" and "exit point" of your codebase. For example, if you're dealing with an API, database or visual front end that has these contracts and may mean something semantically different, then it's fine at the last possible step to translate a value that is undefined into empty string.

eg:

drawHeading(article.heading, article.subtitle ?? '')

It's encouraged to do this at the final most step, and keep all your code between these "exits" and "entrances" to your code as accurately typed as possible, to maximise the above benefits.

I hope this has helped. Of course, this advices generalises to almost all primitives; using number | undefined instead of 0. Using boolean | undefined instead of false and even complex types, using combinations of the primitives.

Finally, have I got anything wrong here? Am I missing legitimate cases for empty strings? I'd love to hear about it :)

Ask DEV - What are your less well known tips for cleaner, better JavaScript/TypeScript?

Sam Jarman 👨🏼‍💻 — Mon, 20 Sep 2021 09:43:22 +0000

We've all seen object destructuring, using prettier and eslint, but what else should we look into? What are your less well known tips for cleaner, better JavaScript/TypeScript?

When you see great code, ask yourself why it is great and can you replicate it? (100 Bytes Of Wisdom: Day 71)

Sam Jarman 👨🏼‍💻 — Sun, 19 Sep 2021 02:27:13 +0000

About two years ago now I had a colleague who wrote some truly lovely JavaScript. Annoyed at myself for not being able to write it so nicely, I chose a reasonably new approach for me and decided to study their code instead. I looked carefully at the choices they'd made for structure and syntax and even asked them how they thought of doing things the way they did. Eventually, I was able to write code in the style that I grew to admire of theirs and I was super happy.

You can catch up with all the other bytes at http://bytesofwisdom.com/

Learning to speak about your code to non-programmers is essential (100 Bytes Of Wisdom: Day 70)

Sam Jarman 👨🏼‍💻 — Sat, 18 Sep 2021 02:43:13 +0000

Too often I see developers struggle to communicate their progress, challenges or even successes to people who are not familiar with programming in the nitty gritty level. This causes suffering for both them and the person they are communicating with. Learning to use figurative languages, simplications, examples and many other techniques to help you communicate accurately but abstractly about your work will serve you incredibly well over your career. You will be called upon more to represent your team, be first in thought for presentations and of course move up the technical chain faster with more promotions. It's a skill a lot of developers don't think to work on, but those who do very much reap the rewards.

You can catch up with all the other bytes at http://bytesofwisdom.com/