DEV Community: Ben

The Importance of Review in Software Testing: Best Practices Explained

Ben — Wed, 12 Mar 2025 09:35:04 +0000

What is Software Review?

What is a review in software testing?

There are different types of reviews that happen at different points in the software development lifecycle (SDLC), and we’ll dive into them all in this article.

Reviewing throughout the entire software development process is key. You shouldn’t just test the final product at the end of development. That’s far too late.

Reviewing in software ensures that you maintain quality, produce the right thing, and do so in a timely manner.

I’ve been in all stages of the software review process many many times over the years. It’s one of the key skills that a software engineer has to be comfortable with outside of writing code.

Objectives and Benefits of Software Review

Whenever I’m thinking of reviews, I have a few key things I’m trying to achieve.

The first purpose I think of for the review process, is to make sure you identify and issues as early as possible in the software development life cycle and fix them. In almost all cases, the earlier you find and fix a problem, the cheaper and easier it is.

Another main purpose I’m striving for in the software review is the make sure that you’re actually creating the software that your users are expecting.

In my experience, It’s pretty common for engineers to veer off from course a little and before too long you are creating quality software, but not the quality software that your user wanted.

A successful review at any point in the review process aims to ensure both the quality and direction of the product.

Types of Software Review

There are many types of software review, including, but not limited to:

Code Review
Peer Review
Technical Review
Pair Programming
Management review
Peer Review / Code Review

The peer review is one of the earliest forms of formal review for the actual code to be checked for quality and direction.

Peer software developers (the reviewer, usually from the same development team) will look at the associated work item (Test Case, User Story, Documentation) and make sure that the code you’ve written matches the intent of that work item.

Once they are happy that the written code matches the intent of the work item, they will do code inspections to look for any bugs or code that could be written in a more efficient or easier to understand manner.

The peer review is usually a collaborative effort and can be picked up by one or more software engineers familiar with the software product and code base.

When I review code, I make sure that I am not just looking for basic technical faults (divide by zero bugs, etc), but that I am also looking for code structure, well named variables, well architeted solutions.

I am very picky with my code reviews as you I am a firm believer that code is written once and read a thousand times. Get it right before it gets merged to main.

Technical Review

A Technical Review is where a group of people from different roles get together to assess the overall state of may parts of the software project.

Participants include:
Software Architects
Senior Developers
Business Analysts
QA

This is a fairly formal review meeting where the group will cover topics such as:

Project Scope
Requirements documents and specifications
Test Plans
Prototypes or MVCs

The idea behind the technical review process is to verify the correctness of the requirements, the direction of the project and the technical roadmap. All of this is to look forwards to try and ensure a smooth project process.

Management Review

This part of the review process is to give high-level stakeholders high-level details about the status of the project.

Managers tend to want to know about whether deadlines are being met (if not, why not) and if the cost of the project is on target.

There’s no software inspections, no looking at source code and no worrying about testing in this review. The key phrase here is “status report”.

Software Audit Review

Software audit review is an exterior review where a single or multiple reviewers outside the development team inspect the software development processes to check compliance with standards, requirements, and specifications.

These tend to be infrequent and only really done at a high level.

The Role of Review in the Software Development Process

Each of the above review types is crucial in its own way to the success of a project.

Reviews highlight issues and miscommunications early on. They keep the project on track and in the right direction.

People are familiar with compounding in finance, but I think that compounding in process is less talked about. With each review process that occurs, the process gets better. You then build upon that better base by getting better at the next review and so on.

Whether formal or informal reviews, reviews get people talking. They gather stakeholders and knowledgeable people in the same place and get multiple minds solving and validating all of the work.

Reviews help companies ensure that their software complies with regulatory and industry standards.

Challenges and Solutions in Software Review

Admin and beurocreacy.

In my experience, these are the two most common complaints from engineers about the software review process.

I’ve worked in many companies with many smart people.

Unfortunately, smart engineers don’t often like many meetings. They don’t like doing Jira admin. They don’t like people scrutinizing their code.

Adding time and effort between a coder and writing code is rarely something you want to do.

However, going slower to get to the end goal faster is always a smart move.

Showing engineers that putting the effort in upfront on generating the correct specifications, and test cases and how reviews play a critical role in delivering what the client actually wants will make your life a lot easier.

Another issue is showing the people involved that the effort they are putting in to code reviews, technical reviews etc has a real world benefit is hard to do.

You can’t run A-B tests on this type of thing. All you can do is highlight the successes that this process has had in the past and how running projects without these processes have failed in the past.

Software development and the development process is about metrics. Prove how this type of project management has worked with stats from the past.

Best Practices for Effective Software Review

Let’s summarise some of the best practices I’ve mentioned throughout this post:

Establish clear objectives and scope for the review.

Assign roles and responsibilities to team members.

Use a structured review process, such as entry evaluation, review process management, planning, preparation, and analysis and exit evaluation.

Use tool-assisted reviews for efficient and asynchronous reviews.

Track metrics to justify the time and brainpower required for code review.

Software Testing and Review: A Collaborative Approach

You should always have automated tests for your code. However, manual testing with QA is a vital step in creating a polished software product.

QA think differently to Engineers. QA look to break things, engineers tend to think about the “happy path”.

Once you as an engineering team have delivered and tested a vertical flow, hand it over to QA to do their thing.

They will bend and twist your software in ways you can’t imagine.

This is a vital step in the software review process.

The post The Importance of Review in Software Testing: Best Practices Explained appeared first on Just Another Tech Lead.

How Often Are Sprint Reviews Conducted or Held?

Ben — Tue, 24 Dec 2024 12:47:17 +0000

How Often Are Sprint Reviews Conducted or Held?

Sprint Reviews are held on the last day of every sprint.

Different teams may have different length sprints, but in general, a Sprint is either two or three weeks.

Therefore, sprint review meetings are held every two or three weeks (always on the last day of the sprint)

Let’s dig into more about what a sprint review meeting is, and what it’s used for.

What is a Sprint Review?

Definition and purpose of a sprint review

A Sprint review meeting is a meeting that is attended by the entire scrum team as well as key stakeholders for the project.

A successful sprint review will be focused on the work that has been completed towards the product, in the previous sprint.

During the sprint review, the agile team (mostly the development team) get key feedback from the stakeholders about whether or not they are on track with what they are working on. Did they deliver what was required and are they on time.

Importance of sprint reviews in Agile development

The sprint review is one of the key agile events in Scrum.

One of the core agile principles is iteration and improvement.

The sprint review allows for small and quick iterations of improvement (product increment) whilst continually improving the product (through feedback).

The Purpose and Benefits of Sprint Reviews

Iterative feedback loop

Agile relies on iteration to succeed.

Agile sprint reviews give regular feedback from stakeholders every two weeks (or whatever sprint review frequency your team has). This is very quick compared with other project planning techniques such as Waterfall.

The quick sprint review frequency affords you rapid adjustment based on feedback from product owners and other key stakeholders.

Early detection of issues

Agile likes to fail fast.

If you’re going to write software that deviates from what your Product and customer want, make sure that someone spots it early and course corrects.

It’s far better to waste two weeks (or however often your sprint reviews conducted) than 6 months (typical for Waterfall process)

Opportunity for iterative refinement

Having your sprint ceremonies every two to four weeks allows you to become better at planning the further through the project you go.

Whereas in Waterfall you may spend months planning the entire project and then set off writing code following the plan exactly (regardless of if it seems wrong), in agile teams, you plan as you go, so the further into the project you go, the better you know the product and code, and the more accurate your planning is.

Adaptation to changing priorities

Anyone who has worked in Software Engineering for long enough (or business in general) will know too well that what is important today is forgotten tomorrow.

The Development Team will be told by the Product owner to lay down tools and focus on new client X who is the saviour of the company. Next week, client Y enters the picture and client X is relegated to the lower leagues of priority.

I’ve seen it time and time again.

Fortunately, Agile has you covered here.

Because you are working in a method that allows for a change of direction every two weeks, you are no more than two weeks away from being able to course correct or have a new priority enter.

Now, let me be clear, I do not approve of throwing away an entire project part way through and having a new top priority enter every couple of months, I’m just saying that I think Agile teams generally deal with this quite well.

Empowerment of stakeholders

Sprint reviews give stakeholders a peek into the otherwise blackbox nature of the software development lifecycle.

Every two-week sprint, stakeholders get the chance to see what has been worked upon as the team members demonstrate their hard work.

Stakeholders then get to give feedback, get status updates and generally be much more involved in the project than they may be without regular sprint updates.

Sprint Review Frequency and Timing

End-of-sprint timing

The Sprint review is held at the end of each sprint. This would generally be every two to four weeks.

The length of sprint is designed to be long enough to deliver significant and valuable work, but short enough so that you can quickly and iteratively deliver to the customer.

Common sprint durations and their impact on reviews

Usually, sprint lengths are between 1-4 weeks.

From my experience, I’ve seen two and three week sprints used the most and to bests effect.

Adapting standard frequencies

Agile wouldn’t be very agile if it didn’t allow for (or even encourage) change based on feedback.

If a two week sprint doesn’t work for you, try a three week sprint. If that’s worse, move back to two week sprints.

I’ve found that different teams and different projects work better within different time frames.

Don’t be afraid to change.

Factors to Consider When Scheduling Sprint Reviews

Project complexity and size

If you are starting a very complex project from scratch, it may be infeasible to deliver anything of value in two-week increments. You may need to start off with three-week sprints if you want to demonstrate valuable output every sprint.

Conversely, complex projects may actually need more regular reviews if you are requiring stakeholder feedback to ensure alignment between the development team and Product.

Team size and distribution

If you are working in an office together and your scrum team is located next to major stakeholders, you may not need as regular stakeholder feedback as if you are all working remotely across timezones.

Whilst I’m a fan of WFH, there’s no denying that information passes quicker and more easily in person.

Stakeholder availability

If the person with the most knowledge of the product you are trying to deliver is the managing director, chances are you won’t be able to tie them down for a couple of hours every few weeks.

When I worked for start ups and small companies, the CEO/Managing Directors were so involved in the product as they typically were product experts. They also had a lot of other commitments, meaning we our scrum events (Sprint retrospective, spring planning, sprint review) had to be at a lower frequency.

Conducting Effective Sprint Review Meetings

Encourage active participation

Agile requires honest feedback.

If you have a psychologically safe environment, people will want to participate more and give their honest feedback.

Psychologically safety also helps create a truly collaborative environment.

Foster open communication

There should be no boundaries between the most junior and most senior members of the review.

Everyone should have a voice that can be heard and taken in.

If people are afraid to share, your sprint review will be less effective.

Focus on progress and improvement

Rather than simply talking about exactly what you’ve worked on, also cover how much overall progress you’ve made for the project overall.

Showcase process enhancements and other improvements to the product and project delivery.

What Happens During a Sprint Review?

Review of completed work

Review the completed work from the sprint and get stakeholder feedback as to whether the work delivers what was expected.

Take note of feedback and plan any required changes in to the next sprint.

Sprint Review Best Practices

Consistency is key: establishing a reliable rhythm

Ensuring that you have a repeated meeting booked out for the same time and the same place, every 2 weeks for the next six months gives people time to arrange other work and meeting to make sure they are able to attend the sprint review.

Prepare for success: crafting an effective agenda

Keep the agenda simple and consistent.

Work through your Jira items (or whatever other planning and tracking software you use) and have pre-recorded demos with a presenter talking through what the room is watching.

Ensure that the agenda is clear, concise, and focused on progress and improvement.

Conclusion – How often are sprint reviews conducted or held?

Well, how often are sprint reviews conducted or held?

At the end of every sprint.

How long are sprints? Between two and four weeks.

The post How Often Are Sprint Reviews Conducted or Held? appeared first on Just Another Tech Lead.

Is the Full Stack Engineer Dead?

Ben — Thu, 31 Oct 2024 09:21:12 +0000

I’ve been pondering recently on the term full stack engineer and if full stack engineers really still exist.

I used to know what full stack engineering meant.

I used to call myself one.

For the last 7 years I’ve been a purely back end guy and haven’t really kept up with the UI trends and job market.

It wasn’t until joining X and becoming more active on the platform this year that I started noticing more and more people calling themselves full stack engineers, and I started to wonder if this was still even an achievable title for anyone.

Introduction: The Rise of the Full Stack Engineer

To understand if it’s still possible to be a full stack developer, we need to go back to its roots.

The term Full Stack Engineer was first seen in 2008, widely accredited to Randy Schmidt, Managing Director at Burns & McDonnell.

Schmidt described full stack developers to be someone who could work across multiple layers of development, from the front-end user interface, to back-end and database and complete the full software development process.

Full stack engineers work across the boundaries of front end development, back end development and databases.

The full stack engineering skill set was perfect for small companies and start ups where smaller web applications were the main focus.

Having full stack engineers who could perform all of these roles appealed to hiring managers, and generally it was feasible to know enough of each of the layers, with the limited technology and frameworks that you could achieve this role.

Initially, this would mean that someone as able to use something like ASP.Net and created the UI, the back end code and some stored procs. Full stack engineers, compared to software engineers in general, often had to master a broader range of skills across different layers of development.

Why Full Stack Developers Thrived Initially

The year is 2010.

People are leaving theatres across the world in a daze after watching Inception. The iPad was the latest and greatest tech that would change people’s lives for good and full stack developers were thriving in an environment with limited frameworks, libraries and tools.

Early web applications were less complex.

The code base was generally bundled as one. Take for example Microsoft WebForms. Your whole code base (minus the database) could be deployed as one.

Applications were generally monolithic and deployed as a single unit.

Sometimes two or three units.

The choices of technology were limited.

Enterprise products were generally made of a combination of the following:

Font End / Web Development:

HTML, CSS and JavaScript
Adobe Flash (already on the way out)
CSS Frameworks like Bootstrap of Foundation coming in

Band-End

LAMP Stack
Ruby On Rails
ASP.Net
Java and Spring

Databases:

Relational DBs mostly
Emerging noSQL databases, but not very widespread or adopted.

This Tech stack is limited and to some extent can be tamed by good engineers.

Now comes the question.

Does full stack engineering mean that you are able to do front end, back end and database in the languages and frameworks you choose, or all languages and frameworks?

I think it would be harsh to say that you needed to know all languages and frameworks to be classed as a full stack engineer.

So by that definition, given that I knew HTML/CSS/Javascript, ASP.Net MVC / SPA etc, as well as C# back end and Microsoft SQL Server, I classed myself as full stack.

I didn’t know Ruby On Rails, but I was confident that if I needed to transition in to being “Full Stack” on Ruby, I would need to retrain my brain on the language, but not learn a whole new paradigm.

The career path for software developers wanting to become full stack was known and was achievable. Similarly, the career path for software engineers, including full stack engineers, was well-defined and achievable, with significant earnings and a strong emphasis on technical skills and education.

Technological Explosion: The Expanding Tech Stack

By the mid 2010’s, the front-end and web development frameworks were starting to get out of control.

Angular, React, Vue, Svelte, Knockout, Ember, Backbone all became prolific in the tech industry.

Some of these were created earlier than the mid 2010’s, but they became prolific then.

I remember learning Knockout.js (which I still love by the way – an MVVM JS framework!) and thinking I’d be left behind if I didn’t also learn Angular (which later did), let alone the ten other frameworks sky rocketing at that time.

The back-end changed too.

We went from mostly monoliths to micro-services.

Express, Django, Rails, .Net Core.

It was now more common to separate your concerns and have services that handled one thing and one thing well.

With the rise of separating your services, also came the rise of more middleware options with which to connect them.

Kafka, Azure Service Bus, RabbitMq, ActiveMq, TIBCO etc.

of course with all of the new complexity of having more technologies separated by more middleware, the idea of containerization (Docker, Kubernetes) and CI/CD pipelines became a must.

After all, you need to be able to test the integration of all of these components.

The Knowledge Overload Problem

It’s now 2024 and we have a problem.

Everyone wants to be part of the full stack engineers group, but the definition has not changed to match the landscape.

We now have too many technologies, frameworks and DevOps procedures for this to really mean anything.

Sure, someone can still know one UI framework, one back end technology and one database and call themselves a full stack engineer. But what good is that really? What does that define?

To be effective, you need knowledge of multiple front end, back end, middleware and database technologies.

We now have a problem of Depth vs Breadth in knowledge terms.

To have knowledge of enough of these frameworks to fulfil that criteria, you probably have a more shallow set of knowledge than if you specialised in a few.

The Rise of Specialization and the Team-Based Model

Companies in recent years (from what I’ve seen) have been replacing Full Stack with more specialised roles compared to the broader category of software engineers:

Front end, Back end, dev ops, cloud engineer etc.

These individual specialists as a team are effective. They have deep knowledge of their domain and as long as processes and communication are good, are able to build spectacular things.

Deeper expertise tends to mean higher efficiency and better quality control.

The Modern “Full Stack” Engineer: Still Alive or a Myth?

Does the Full Stack Engineer still exist?

Well that depends on your definition.

In my opinion, it’s a murky area. It always has been.

The reality is, when building large scale commercial projects, generalisers (or full stack) will need to work with specialists.

I think Indie Hackers are certainly full stack. I think small companies with smaller code bases can possibly be full stack.

Can you be an industry wide successful full stack engineer? Probably not.

People are emerging now as “T shape engineers” which means a generalised knowledge of a wide variety of areas, but specialising in one. This concept fits within the broader category of software engineers, who often need to balance generalist skills with specialized expertise to advance in their careers.

I think this is a good approach.

Polyglot engineers are happy writing code in multiple languages, but they may all lay in the same domain (back end for instance).

Are Full Stack Engineers Truly Dead?

Well that answer really depends on what your definition what Full Stack Engineers are.

If your definition is:

Knows at least one front end/web development framework
Knows at least one back-end framework
Knows at least one database

Then probably not.

If your definition is: Can apply for any Full Stack Engineers role regardless of the technologies that are required, then I would say yes, the term Full Stack Engineer is dead.

I would suggest that T Shaped Engineer is more fitting and a better target to aim for – A broad knowledge of a lot, with one or two pillar topics of expertise.

As time marches forwards, the role of the Software Engineer will change anyway. Full stack engineers fit within the broader category of software engineers, who are known for their significant earnings and diverse career pathways.

AI will be guided by human engineers to craft solutions.

Maybe Full Stack Engineers can be rekindled with the help of AI?

Who knows.

Conclusion: Embracing the Evolution of the Full Stack Engineering Roles

What’s my point with all of this.

Nothing really.

I just thought it was interesting.

I thought it was an unfair bar for people to set for themselves these days and not necessarily the career path many should take.

Full stack developer is term that was created in a time we no longer live in.

What title do I give myself? Well, a Software Engineering Manager now, but Software Engineer would be my title of choice if I wasn’t a manager.

The important thing for an engineer is that they are adaptable. That they can use problem solving and abstract skills to solve problems in any framework and language. That they can hone the knowledge that they have gained over the years to spot pitfalls and advantages to different platforms and frameworks.

Be adaptable and you will thrive.

Appendix

This is the 25 front end Frameworks that are considered “large in the market” in 2024:

React – Popular JavaScript library for building user interfaces, developed by Facebook.
Vue.js – Progressive framework focused on simplicity and flexibility.
Angular – Full-featured framework by Google for complex, large-scale applications.
Svelte – Compiles components at build time for improved runtime performance.
Next.js – React-based framework with server-side rendering and static generation.
Nuxt.js – Server-side rendering framework for Vue.js.
Ember.js – Robust framework with strong conventions for ambitious applications.
Preact – Lightweight alternative to React, optimized for performance.
Solid.js – Fast, reactive framework with fine-grained reactivity.
Lit – Web components library by Google, focused on minimal overhead.
Backbone.js – Lightweight framework that provides structure with models and collections.
Alpine.js – Minimal framework for handling JavaScript behavior in the DOM.
Stencil – Compiler for generating standards-based web components.
Qwik – Designed for delivering instantly loadable applications.
Marko – Framework with reactive components and fast server-side rendering.
Mithril – JavaScript framework with a small footprint, ideal for SPAs.
Hyperapp – Tiny framework focused on simplicity and modularity.
Aurelia – Framework known for its clean syntax and extensibility.
Meteor – Full-stack framework, but popular for front-end development with JavaScript.
Dojo – JavaScript framework known for building high-performance applications.
Inferno – High-performance, React-like library focused on speed.
Blazor – Front-end framework by Microsoft for building interactive web UIs with .NET.
Riot.js – Simple, lightweight framework for building UI components.
CanJS – Focused on building maintainable and performant applications.
VuePress – Static site generator powered by Vue, primarily for documentation sites.

The post Is the Full Stack Engineer Dead? appeared first on Just Another Tech Lead.

Code, Culture & Cognition: 24.43 – Fast, Good or Cheap. Pick Two.

Ben — Fri, 25 Oct 2024 13:06:32 +0000

What’s been on my mind this week?

This week I’ve been thinking a lot about rigor in software engineering.

I write software for Investment Banks, Hedge Funds, Central Banks and the largest financial institutions in the world.

For those who aren’t familiar with DORA (Digital Operational Resilience Act), it’s a new regulation that’s coming in to play in the EU to enforce certain guidelines to technology written for financial institutions.

This is to help ensure the safety of everyone’s money.

It’s pretty important.

Well, at the opposite end of that spectrum are the ship fast, ship often crew of small contributors and indie hackers.

I have admiration for them and I think they are amazing at what they do. They create things very very quickly, get feedback and get money.

I don’t for one second believe that they are intentionally putting out insecure or badly tested code either.

This is by no means a shot at those people, it’s an observation from someone who has had to build very large-scale, secure, and extensible systems over the years.

Speed comes at a price.

It’s the Iron Triangle. Pick two: Fast, good or cheap

Writing and shipping at speed is great to get initial customer feedback. It’s vital in fact. There’s no reason to pour your heart soul and energy into a project that no one will use or need.

However, once you have gained the initial market fit, you need to reconsider your code base.

The two general practices for gauging product, and market fit are:

Ask people to sign up for your service before you even create anything. This shows positive intent
Create an MVP that people can actually use. If they use it, build that out.

Once you have a solid understanding of if your product is wanted and people would pay for it, you need to take a step back and ask yourself:

“Is the code which I have shipped so far good enough to be the base of a larger project that people can rely on for safety and quality?”

If the answer is no, take a step back and assess.

You know people want it, you know people will pay for it. Put the time and effort in to building it properly.

Top Software Engineering Personal Statement: Tips and Examples

Ben — Fri, 25 Oct 2024 08:16:20 +0000

A good Software Engineering Personal Statement statement for software engineering is your ticket to a tech career.

As computer technology continues to evolve, writing a good personal statement is more important than ever.

With my years of reviewing interview applications I’ll show you how to write a great statement that shows your passion for software engineering and computer tech.

Writing a Strong personal statement for software engineering

Your statement should start by telling your story of how you got into software engineering, especially if you started early.

Many successful candidates show their natural aptitude for computer programming from an early age or early projects.

Whether you started by exploring computer systems or teaching yourself to code, these early experiences form the foundation of your narrative.

When writing your UCAS personal statement focus on authenticity.

Universities want to see real enthusiasm for computer science and practical experience.

Your statement should show both your theoretical understanding and hands on experience of computer tech and how these have prepared you for a career as a software developer.

Don’t forget admissions tutors are looking for more than technical knowledge.

They want to see your motivation, creativity and potential for growth in software engineering.

Consider including examples of how you’ve overcome challenges or contributed to team projects.

Tell them of times you’ve shown leadership skills, or used different methods of running programs.

What is your favourite programming language and why?

Personal statements should be just that. Personal.

Software Engineering Fundamentals

Software has changed the modern world so you need to show you understand the basics.

Your statement should show how computer science intersects with different industries and innovations including artificial intelligence and data analytics.

Key areas to cover in your statement:

Your experience of different areas of computer science
Your approach to problem solving in technical situations
How software engineering drives innovation
Your practical computer programming projects
Emerging computer tech trends

Consider including specific projects or experiences that show your understanding of the basics.

This could be coursework, personal projects or extracurricular activities that show your commitment to learning and applying software engineering concepts.

Technical Skills

In software engineering theoretical knowledge must be balanced with practical skills. Your statement should show:

Projects that demonstrate your computer science skills
Real world applications of your software engineering skills
Problem solving in development scenarios
Experience of different programming languages
Software development methodologies

Include specific examples of how you’ve applied computer science concepts in real world scenarios.

This shows not just your knowledge but your ability to turn theory into practice.

Describe any significant projects you’ve done, challenges you’ve overcome and lessons you’ve learned from hands on experience.

When talking about technical projects focus on your problem solving process rather than the end result.

Explain how you approached the problem, what alternatives you considered and why you made specific technical decisions.

Future and Professional Development

Software engineering is constantly evolving so continuous learning is essential.

Your statement should show your commitment to growth and your vision for the field.

How do you plan to build on your computer science foundation and adapt to new ideas and emerging technologies?

Consider:

Areas of software engineering that interest you
Technologies or methodologies you want to get into
How you keep up to date with industry news
Your long term career goals
What you hope to contribute to the field

Writing and Structure

When writing your UCAS statement keep it simple and logical from your initial interest in software engineering to your future goals.

Remember:

Start with a hook that shows your passion for software engineering
Show practical computer programming experience
Show understanding of computer science basics
Highlight problem solving experiences
Link your background to your software engineering goals

Keep your writing clear, concise and jargon free unless you really need to use technical terms.

Each paragraph should flow into the next to tell the story of your journey and aspirations in software engineering.

This personal statement is also a good way to show off your communications skills.

Communication skills are key skills that help in solving problems as a group, team work uni business in general.

Final Thoughts

Your statement should:

Show your commitment to computer science
Show software engineering experience
Show understanding of computer tech
Show problem solving
Show a clear vision for your future in software engineering

Remember to proof read carefully and make sure it flows and includes all the key points.

A good personal statement can set you apart in a competitive software engineering and computer science field.

Revising and Refining

Take time to review and refine your statement multiple times.

Share it with mentors, teachers or professionals in the field for feedback.

Consider getting both technical and non technical people to review it as this will help ensure it’s technically correct and readable.

Look out for:

The overall flow and structure of your story
The technical vs personal balance
Clarity of your examples and explanations
Strength of your opening and closing paragraphs
Authenticity of your voice throughout

Try to submit a statement that meets the formal requirements and shows your real passion for tech and development.

With the right mix of technical knowledge, practical experience and personal insights your statement will show why you’re the perfect candidate for software engineering.

Hopefully, you now have all you need to perfect your software engineering personal statement.

The post Top Software Engineering Personal Statement: Tips and Examples appeared first on Just Another Tech Lead.

Understanding Idempotency in Software: A Guide to Error-Free Systems

Ben — Fri, 18 Oct 2024 11:44:15 +0000

Understanding Idempotency in Software: A Guide to Error-Free Systems

What is Idempotency in Software?

Idempotency in it’s simplest form is:

The ability for a service or consumer to read the same message multiple times yielding the same results as if they only read it once.

To state that as an example:

Imagine I have a Kafka topic with one producer and one consumer.

The producer takes “new user” data from a web UI and publishes that in a message to Kafka in the form of a “createUserRequest”.

The consumer’s job is to read the createUserRequest and:

Create a row in a database table

Send a welcome email

It should not matter if the consumer reads that createUserRequest 1 time or 100 times, there should only ever be one row in the database and one welcome email sent. Idempotency guarantees this. You will get the same result from that service if you call it once or many times.

I.e. An idempotent service can process the same request more than once without the side effects happening more than once.

Idempotency is essential in distributed systems, where network failures or system crashes can lead to the same message being processed multiple times.

Idempotent Functions

As well as having idempotent services, you also have idempotent functions.

Idempotent functions produce the same output given the same inputs, regardless of the number of times they are applied.

Same input. Same outcome. Same result.

Importance of Idempotency

Imagine you had a system that was dealing with charging a client’s bank account for purchasing a new item. Let’s say an iPad.

You have one service whose job it is to deal with the purchasing (let’s call it purchaseSvc) and another whose sole purpose is to take a request to withdraw funds for a purchased item (let’s call it fundsSvc).

Imagine that purchaseSvc has a bug whereby it sends the same message twice due to a looping error.

This means that for the same user action (buying one iPad), the fundsSvc receives the message twice.

Now let me ask you this.

Would you be happy to be charged twice for the purchase of one iPad? Probably not!

Through the fundsSvc service being idempotent, it should recognise that it has received multiple identical requests and not process it a second time. Your hard earned money is safe!

A duplicate message should not affect the running of a system.

Idempotent operations are crucial for scalability and reliability in distributed systems.

Idempotency simplifies error handling, concurrency management, debugging, and monitoring in operations and APIs.

Idempotent vs. Safe

Idempotency ensures that repeated operations yield the same outcome, while safety ensures that the returned value is not modified.

A safe method does not change the value that is returned, it reads – but it never writes.

Idempotent methods are safe, but not all safe methods are idempotent.

Implementing Idempotency in APIs

In distributed systems, the use of unique identifiers on the messages is hugely important.

There are many types of IDs that are used on messages in distributed systems: SagaId, TransactionId, correlationId, messageId.

The one we care about for idempotent operations is the messageId. This uniquely identifies that specific message.

Now that we have a way to identify if multiple requests are actually the same message multiple times, we can put in place the code required to be idempotent.

When first reading the message, you want to take note of the ID. You then need to do a check against a local database to see whether or not you have already seen that message.

There are two different outcomes to this check:

You’ve not seen this message before. You should insert a row into your database stating that you have now received the message and process the message

You have seen the message before, and the message is completed. Disregard this new message as you don’t want to apply the same operation multiple times.

Remember, the key point here is that no matter how many times you receive the same message, you don’t want to process it more than once.

Idempotency is crucial in APIs because a resource may be called multiple times if the network is interrupted.

Benefits of Idempotency

Being Idempotent allows systems to be consistent and predictable. Even when faced with network disruptions, service restarts, and retries, you can guarantee “process at most once” semantics and ensure that you get the same result when calling a service once vs many times.

A service being idempotent also simplifies error situations where having duplicate data may cause bugs. How would you for instance undo the duplicate withdrawal of funds mentioned above?

Some errors such as a duplicate row in a database may be “easy” to undo, but what if the side effect of processing a message is updating an external system to yours? Do you always have a way to undo that?

Idempotency in API Design

GET, HEAD, PUT, and DELETE request methods are idempotent, as they don’t change the data or have the same effect when repeated.

POST is not inherently idempotent, as making the same POST request multiple times can result in different outcomes or create multiple instances of submitted data.

Idempotency in API design ensures that the server’s state remains consistent and unchanged, even if the request is repeated multiple times.

Idempotency in Distributed Systems

Being idempotent is a concept. That concept can be implemented as part of a point-to-point call or in pub/sub architectures.

In distributed systems, one subscriber consuming a message more than once could lead to a chain effect.

If service X reads from your middleware and then produces a message back which downstream consumers pick up, service X reading the message and processing it more than once leads to their downstream services then having multiple messages to consume (probably with their own unique Ids so they seem like two genuinely separate messages).

Idempotency in distributed systems ensures that even with network failures or system crashes, your system will have overall correctness.

It is important that all services in a distributed system define their publish and consume semantics. Do they guarantee to consume at most once? Do they guarantee publish at least once?

Idempotency in Database Migrations

To properly be able to test and roll out schema changes to a database, you need to be able to re-run the script multiple times ensuring that each run is not impacted by the previous or next run.

Usually you would do this via checking if assets exist, dropping and then recreating.

Something like:

Idempotency in Message Queueing Systems

A message queue can make a system idempotent by ensuring that even if a message is delivered multiple times, the operation it triggers is executed only once.

Idempotency in message queueing systems ensures that the system can handle retries and failures without affecting the overall correctness.

Idempotent message queueing systems ensure that the same message is not processed multiple times.

Conclusion

Idempotency is a powerful concept in software engineering.

Idempotent operations guarantee that the same request is not processed more than once and the receiving service does not have the same effect twice: i.e. sending an email twice, creating two rows in a database etc.

By implementing idempotent functions, APIs and infrastructure architecture (queues) systems become more robust and less prone to failure and data inconsistency.

The post Understanding Idempotency in Software: A Guide to Error-Free Systems appeared first on Just Another Tech Lead.

Effective Junior Software Engineer Resumes: Examples and Expert Tips for a Winning Job Search

Ben — Tue, 08 Oct 2024 05:49:21 +0000

When thinking about Junior Software Engineer Resumes, we first need to define what a junior software engineer is.

This may be controversial, or maybe not, but my definition is any engineer with less than four years experience.

Now, bear with me here because it does get a little tricky when we start to talk about “experience”.

A Software Engineer who has done the same thing every year for twenty years could be considered to have one year of experience twenty times over.

However someone with 4 years of experience who has had two completely different roles in different environments and different sectors could be considered to have a wider variety of experience.

For the sake of having to come up with a generalised number of years, I say less than four years is a junior software engineer.

Great. Now that we’ve got that out of the way, let’s look at what the role of a Junior software engineer actually is.

Understanding the Junior Software Engineer Role

I find that one of the most important things you can do with any employee is define what their role should be.

Without this common understanding, it’s difficult for both leader and employee to measure if someone is doing well.

As always, a generic job title will differ from company to company, but in my experience, these are the common roles that make up a Junior Software Engineer role.

Technical skills

A Junior software engineer will develop, test and implement software solutions usually under the guidance of asenior software engineer.

This means writing code that may or may not have been designed by the junior software engineer.

The extent and complexity of the tasks given to the junior will depend on the company and competency of the junior software engineer.

Programming languages will vary depending on the company, but in general if you are a junior the company will more than likely not require previous experience in that programming language.

Other areas such as database management, web development or system performance may or may not be a factor depending on the role for which you are applying and the level of experience you already have.

I would suggest if you are applying for a role that is focused on something like system performance, that you have a solid understanding of the fundamentals even if you don’t have first hand experience.

You will want to be able to debug existing software as well as write new, green field software and have some basic understanding of user interfaces (even if you are applying for a back end role, it doesn’t hurt)

Methodologies

Being a Software Engineer isn’t just writing thousands of lines of code with your headphones on and some techno blazing. Despite what the movies show us, coding skills aren’t the only thing you need to be a great software engineer.

As a Junior software engineer, you won’t need to have experience with project management methodologies, but having a basic understanding of a difference between agile methodologies and Waterfall will impress hiring managers.

Problem solving skills

All useful software solutions solve problems. They meet customers needs and make the clients life easier.

As a junior software engineer, you may or may not have real world experience in solving the clients problems, but you should have a solid set of problem solving skills.

One of the differences between average engineers and great engineers is the ability to truly understand the problem that the client is having and using your skills to solve their problems.

As Henry Ford once said:

If I’d have asked customers what they wanted they’d have said “faster horses”

The great engineers understand the problem and create a solution. Average engineers just do what the client asks.

Soft Skills

No large companies succeed based on individual people working in silo’s, especially those who are trying to solve clients needs.

For a junior software engineer to grow effectively, they will need to have good communication skills and general soft skills to enable them to ask the right questions, get the right feedback and build a community of people around them that can help them develop as a software engineer.

When hiring managers are interviewing, they are interviewing for fit as much as technical skills.

If someone isn’t a team player or won’t fit in to a team, they will likely not get the job.

There’s nothing more costly than a bad hire and nothing more toxic to a good team than a bad fit.

Crafting a Winning Resume

Resume Structure and Layout

Here’s where the fun starts.

How do you get someone who does not know you, to notice you? How do you differentiate yourself from the rest?

Summary / Introduction

Before we talk about the context of the CV/Resume, let’s talk about personalisation.

You should always (ALWAYS for those who couldn’t hear me at the back) personalise your CV for the job to which you are applying.

I’m not saying that you should change it to lie and make yourself seem more suited, I’m saying that you should emphasise experiences and skills that you do have that are more relevant to the role in question.

Cover letters are a matter for another discussion.

Start with a quick elevator pitch of yourself. This should grab attention and let them know why they should continue to read your CV. Going back to what I said above about personalising the CV to suit the role. Do that here. Make them understand in the first one or two sentences why you are a good fit for the role.

After the summary section comes the skills.

Skills

Highlight any skills that are relevant to that role at the top of the skills section (again, personalise the CV) to grab the attention of the interviewer. If the role requires database knowledge, list the databases on which you have worked at the top. If the role requires that you ride a horse. Horse riding should be the very top skill in the section. You get the point.

“Technical Skills” is a broad term. You can include (but are not limited to):

Programming Languages
IDEs
Project management software
Problem solving skills
Version control systems
Software development methodologies

Work Experience

Now, in reverse chronological order, list any relevant software engineering work experience.

These should be fairly brief as your whole CV should be no more than 2 pages of A4, but with enough information to convey what you worked on.

You want to emphasise deep knowledge of what you worked on here. The customer problem it solved, the deliverables and your involvement.

I learn nothing when I read “Converted 10 python services to python3.9”.

I want to know the reason behind it, the impetuous, the benefits, the technical challenges. Bring me in to the story.

Showcasing Your Experience and Skills

Junior software engineers may not have a large backlog of work achievements from which to draw.

You may however, have contributions to open source software, personal projects, your own Blog, GitHub repo etc.

Highlighting these may set you apart from the pack. In my view, these are not the same as commercial work experience, but certainly do show an extra level of dedication and willing to learn.

You may also have interned somewhere or done a placement. These are hugely important to include at the start of your career.

Highlighting Your Education and Certifications

The end of the CV is where you add your qualifications. These again are generally in reverse chronological order.

List all of your relevant (or not relevant) degrees such as computer science, maths etc, with their start and completion dates as well as the university from which you graduated.

Highlight any specific modules or courses you may have done that relate to the role to which you are applying.

Add any extra qualifications or relevant technical skills that you believe can be transferred to the role of software engineering.

Essential Skills for Junior Software Engineers

Programming languages

You should known at least one programming language to start your path in to software engineering.

Whether that be from a formal education from a computer science university, or a personal project that you are able to display to the hiring managers.

If you’re not sure where to start, google “top programming languages in demand”. Or just choose Python (Python appeared in 27% of job adverts in the UK last year)

Software Development Tools

Tooling sucks a Git, Jenkins, Docker. All of these are considered fairly essential in the day to day life of a software developer. I would say that these are less relevant in a hiring situation of a junior software engineer though as they can be easily taught.

Problem Solving abilities

Most of software engineering boils down to solving problems. If you have the right mindset and have a brain that allows you to logically step through breaking down a problem, you’ll go far in software engineering.

Software Development Patterns

If you want to set yourself apart from the crowd, learn some design patterns and methodologies. Tell the hiring managers where you have applied them and why. Show that not only can you solve a problem, but you can solve it with good design in mind.

Again, as a junior software engineer, you may not require this. But it will be a differentiator.

Software Testing

Again, you don’t need to have deep knowledge of this as a junior software engineer, but you need to have an understanding of software testing and how that leads to high quality software solutions.

Tips for a Winning Job Search

I mention this once of twice above, but tailor your CV to the job to which you are applying.

This really is key.

You should ensure that the skills and experience you have that match the role for which you are applying are in the opening summary and top of the skills lists.

Look at the job advert and look for keywords that they use. See if you can build these keywords in to your CV. When hiring managers are skimming through CVs, their eyes will be drawn to the words and phrases that they themselves wrote in the advert.

Get your professional summary at the top as good as it can be. Really really focus on this. As the saying goes, “you don’t get a second chance at a first impression”. This may be the make or break for you. Write it once, sleep on it, read it and re-write it. Repeat this until you are really happy with it.

Order your technical skills section based on the needs of the role to which you are applying. The most important skills for that particular job at the top. The programming languages that you know that are applicable to the role, highlight them. No really. Make them bold. Make it easy for the person reviewing your CV. If you make their life easier, you are more likely to get an interview.

Write enough detail that shows the reader that you have a good understanding of the projects on which you worked, but being brief enough that they don’t get bored. I can guarantee you that they won’t be reading three full A4 pages of a CV. Make it snappy, make it engaging.

Highlight the qualifications that you have that contain relevant skills to the job. Computer Science degree – include this front and centre. Recognised certificate in some form of web development – include this. Certificate in 100m backstroke – probably leave this off.

There are two approaches to choosing where to send your CV:

1) Shotgun the CV – send it to as many people as you can. Regardless of if the job is perfect. As long as they use the phrase “junior software engineer“ or “Software development”, send send send. The sheer volume should get you some responses.

2) Tailor your job search to the job descriptions that specifically meet your needs. The programming languages that you know. The software development methodologies that you have already used. The technical skills that you already have. This will allow you to truly tailor the CV and have a better chance of rising to the top of the pile of applicants.

Junior Software Engineer Resume Examples and Templates

If you would like me to send you some pre-written templates, sign up to my Newsletter and reply to the welcome email with the word “Template”

Getting Feedback and Improving Your Resume

Getting feedback on your CV/Resume is crucial. Sometimes you can just be a little to close to it to see the wood for the trees.

Ideally you would ask someone in the software engineering field to look over it and give tips and feedback, but if you don’t have that option then at least get someone to read through it and give you feedback on the grammar, phrasing and detail.

When people write about projects on which they have worked, they can sometimes miss details that they think are obvious. Having an extra set of eyes who could critique the write up of your professional experience section and tell you where you may have missed some well needed information is crucial.

Keep your CV up to date and fresh.

As you develop your skills, update your CV to reflect the new experiences and achievements.

Conclusion

The job market is tough. More people than ever are entering the field of software engineering.

A well-crafted junior software engineer resume is essential for a winning job search.

By highlighting relevant skills, experience, and education, you can increase your chances of getting through to the interview stage.

Remember to tailor your resume to the job description, use keywords, and focus on strategies specific to junior software engineering roles.

The post Effective Junior Software Engineer Resumes: Examples and Expert Tips for a Winning Job Search appeared first on Just Another Tech Lead.

How to ACE a Software Engineering Interview

Ben — Tue, 11 Jun 2024 12:04:24 +0000

How to ACE a Software Engineering Interview

I’ve recently joined X and signed up for the Software Engineering community.

There have been a lot of posts from newer engineers who are nervous or unprepared for interviews they’ve got coming up.

I thought rather than answer them each independently, I’d write a post about how to prepare for a software engineering interview.

What are my credentials?

I’ve read thousands of CVs/Resumes and interviewed probably a thousand people in various companies for which I’ve worked.

I ran the interviewing cohort of about 30 interviewers in my current company for about 4 years in which I helped set the standards of what is expected for an interview, ensured the same process was adhered to and set the expectations of what a good candidate looked like.

I’ll outline here how to prep in a non technical manner for anyone with less than five years of commercial experience. So people I would still include in the Junior bucket.

Disclaimer

Every company has a different interview process. I’ve interviewed people when I worked at start ups, software houses and large multi national companies.

Each process will be different.

Here I will just talk about the common traits between all interviews, whether they be for small companies or large multi nationals.

Before the interview

Know the company

This may sound obvious, but many people overlook this crucial step.

Research the company. Who are they? How long have they been in business? Who is their primary customer? What service do they offer?

All of the information you need to do this will be available on their website.

Bonus points to those who find out something interesting about the company through their social media profiles or some obscure method.

Interviewers will be impressed if you’ve done your homework.

Ask HR / the recruiter what to expect

They won’t tell you specifics, but you need to know how long you’ll be there (is it an hour or a day long interview) and the rough overview of what to expect.

In larger companies it will look something like this:

Initial tech interview with one or two engineers
Second tech interview with one or two engineers.
Interview with Tech Manager
Interview with HR.

This can last up to about 6 hours.

In smaller companies I’d expect you’ll only be in the interview up to two hours.

Ask if there will be a test. If so, should you prepare something to take (the answer will more than likely be no, but this will get their HR talking and they’ll hopefully give you some more information than they normally would if you don’t ask).

You should expect one or all of the following from a technical perspective:

Multiple choice test with just you in the room (run away if this is how they interview)
Pen and Paper / Whiteboard pseudo code to solve a problem with an engineer.
Actually writing code solve a problem. They may or may not require the code to be working at the end.
Review an existing piece of code.
A game of “find the bug”

All of these will be put in place to show how you solve problems.

They may also want proof of excellence in a particular field/language if that is what you are claiming.

Some companies are looking for people who have an in depth knowledge of the language(s) they use. Others are looking for smart people who can solve problem regardless of language. Find out which you are applying for.

Prepare at least three questions about the company

If you are planning on attending an interview and have not thought about what you will ask the interviewer(s), don’t.

Not only is an interview a two way process, but the interviewer will not look kindly on someone who has absolutely no questions about the role and company to which they are applying.

Come up with three non generic questions, memorise them and if possible have follow up questions to the answers. Something like:

Candidate: “I see your main clients are people in the X industry. Do you have any plans to grow in to Y industry.”

Interviewer: “Great question. We’ve nearly saturated industry X, but we don’t feel industry Y is the right fit for our product”.

Candidate: “Out of interest, why do you not think your product would work in industry Y”?

You see. This isn’t a fire and forget question. It shows you listened, took in what the interviewer said and had a follow up question.

It’s engaging and shows you are able to properly converse.

Jobs are just as much about quality information exchange through conversations as they are about technical ability.

If you have multiple stages to your interview (one with an Engineer, another with a Manager, another with HR), don’t hesitate to ask your questions more than once.

Each person you ask will give you a different perspective and I encourage people I interview to ask my colleagues the same questions as they asked me. It gives them so much more information.

Prepare your introduction speech

You will want to have about a two to three minute introduction committed to memory word by word.

Do not try and wing it. You get a limited amount of time with an interviewer and every second counts.

As the cliche goes, you only get one chance at a first impression.

Tell the interviewer:

Who you are
How long you’ve worked in the industry
Any relevant experience to the role you are applying to
[Optional] Why you are looking to move jobs and why you chose to apply to them.

Keep it brief but full of pertinent information. No one cares if you like to watch movies on the weekend or go hiking with your friends.

Practice this speech out loud in front of the mirror until you have the cadence and speech pattern figured out.

Having this level of preparation should help with any nerves you have going in to the interview.

This will almost be the first thing you say in the interview, so if you can get it nailed and delivered perfectly, it should give you confidence for the rest of the interview.

Ensure that you know everything on your CV/Resume in detail

Don’t write something on your CV that you have not done or cannot talk about in detail.

If you say you can ride a horse. Make damn sure you can ride a horse.

It’s no enough to say “yes, I worked on project X”.

You need to be able to say:

Yes, project X was great. It was initially brought about to solve [enter client problem here]. We initially decided to use [language / framework] as it was best for the problem because [enter reason].

Throughout the project we found problems [X, Y, Z] and decided to pivot to using [something else] as the [performance, scalability, extensibility] wasn’t good enough.

If I had to do the project again I think I’d change [enter lessons learned here]

You need to be able to impress upon the interviewer that you learned along the way and truly understood all of the decisions that were made along the way, even if you did not make them.

No one makes the correct decisions first time around, but if you don’t learn from your mistakes you’re doomed to make them again.

I see questions a lot about “how many projects” do I need to have done before I go to an interview.

I’d say it’s less about how many projects and more about the variety of the projects you worked on, and in how much detail can you talk about them.

The day of the interview

If you’ve done all of the above, you’re prepared.

Take a deep breath, stay calm, go to the toilet before you get in to the interview and stay hydrated.

To paraphrase a quote the navy seals:

You don’t rise to the occasion, you sink to the level of your preparation

Be courteous, kind and interested.

I’m assuming by this point you’ve also got enough knowledge of your chosen language and prepared for the technical side.

After the interview

You’ll likely hear nothing for days if not weeks.

If you don’t get the job, ask for feedback.

In the UK, the company is required by law to give you any notes that were taken during the interview.

If they wrote it down, they have to show you.

Every interview you do is preparation for the next interview.

It is not wasted time or effort if you don’t get the job, it’s experience to take to the next interview.

Write down the questions that the interviewer asked you so you have a bank of interviewer questions somewhere.

Go through them, rehearse new answers and be ready for next time.

If you did get the job, amazing, well done!

Conclusion

The biggest thing you can do is prepare.

If you prepare, the nerves will sort themselves out.

Be confident. Know everything you’ve claimed on your CV. Understand the company to which you are applying.

If you feel that I’ve missed anything out, please feel free to email me at ben@justanothertechlead.com or contact me on my Contact page.

The post How to ACE a Software Engineering Interview appeared first on Just Another Tech Lead.

Tech Leadership in Software Engineering

Ben — Fri, 10 May 2024 10:03:01 +0000

Before starting to seriously write about my role as a leader in the Software space, I thought I should right about the frequently used terminology around being a technical lead in the tech world. Below, I’ll delve in to the different levels and types of leadership that I’ve seen and that I will write about. Most job titles are open to interpretation and can mean different things in different companies, so I’ll try and just define them in the most common way as I’ve seen them.

I won’t go In to leadership styles in post as that is a very different subject and requires an entire post series of it’s own at some point in the future.

What is a leader?

I bet you didn’t think I’d go this far back to basics, did you!

leader

noun [ C ]

leader noun C

a person in control of a group, country, or situation:

a religious leader

“He’s a natural leader”.

“She was elected as leader of the campaign group.“

Oxford English Dictionary

The Oxford English Dictionary defines a leader as: “a person in control of a group, country, or situation”. This is a very clinical definition devoid of nuance. When a definition of a leader uses the word “control” it is often (quite rightly) derided. There are many different camps when it comes to leadership, but I’ll just choose two for comparison here:

Leading by strict direction and a singular vision. Essentially autocracy using authority.
Leading by example and using consensus.

There’s essentially having people work with you or for you. I realise that there is a broad spectrum of types of leaders, so I definitely don’t want to define it down to just these two forms. I just want to highlight these two as they will become pertinent later in this post.

I’m more of a fan of the Harvard Business Reviews definition of a leader:

Leadership is the accomplishment of a goal through the direction of human assistants.

Harvard Business review

So, a tech lead can either lead by authority or without or authority. Let’s take a look through some of the job titles and leadership roles in the Software Engineering space.

Senior Software Engineer as a Tech Lead

Whilst you can certainly be a leader as a Junior, generally the SSE is the earliest form of tech leadership. The SSE is probably the largest category of software engineer. When I started working in the industry, the general consensus was that when you’d hit five years of commercial experience, you could feel comfortable calling yourself a senior software engineer. In my current place of work, I think the definition is anyone with three years or more experience. You are a senior software engineer much longer in general than you would be a junior. Not all engineers want to rise through the corporate ladder beyond this as they like writing code. SSE is the highest population of workers in Software Engineering.

Leadership without authority is essentially what you have to do as a senior software engineer. You infrequently would get a position of direct authority in this role where you would have reports, but in no way does that mean you can’t be a leader. Many of the people I picture as leaders during my years have been SSE’s. I listened to them and took instruction because they earned it.

Leading without authority requires that you gain the respect from your peers. You colleagues needs to see you being extremely competent and leading by example. With these virtues being shown, leadership without authority is not only possible but tend to organically happen. Leadership here tends to come in the form of mentoring more junior (that could still mean other SSEs) colleagues in both product and technical term. An SSE may choose the framework or language for a particular service or piece of code and be able to get this through consensus without the power to tell, but with the power to convince people it’s the right thing to do.

Scrum Master as a Tech Lead

In order to stick to the topic of tech leadership, I’m going to talk about a scrum master here in the terms of an Engineer who remains technical but takes on scrum master duties, not a purely non technical scrum master.

In some teams, a scrum master is a non directive leadership role whereby one is in charge of running the sprint ceremonies and ensuring your work tracking tool of choice is up to date. Other companies however see the role of scrum master as all of the above plus an element of people leadership. I’ve not known of scrum masters who have engineers directly report to them, but I certainly do know scrum masters who decide on what work goes to which person, has the authority to tell someone to stop working on a task if priorities change and chase people when their work may be late. Scrum Master is a leadership role when it’s allowed to be.

Technical Lead as A Tech Lead

A Technical Lead has to fall in the tech leadership list, the clue is very much in the name. A Tech Lead has ownership and authority of all things technical within a team. They choose which language to use, which frameworks to use, which patterns to follow, what the architecture will look like etc. Tech Leads seldom do people management, they are generally the career progression next step for SSEs. The leadership aspect here is pretty obvious, it’s leading the teams technical identity and agenda.

Software Engineering Team Lead

Here’s where things get fuzzy. I’m sure that there are many people who have fixed definitions of this role and the next role I’ll define (Software Engineering Manager), but to me they can mean different things in different organisations. I’m going to write here based on my experiences (which is all I will ever do).

Without wishing to define the definition by restating the problem, a Software Engineering Team lead leads software engineering teams. Well done me. The reason this is quite hard to define, is that a SETL has to wear many hats and those hats can depend on the organisation in which they work. Some of the more common hats they may need to wear:

Mentor
Technical Lead
Product
Business Analyst
Scrum Master
Communicator
Team Cheerleader
People management
Project Manager
Problem Solver

As you can see, the list is long and varied. I’ve been a SETL in three different companies and the roles all looked totally different. The roles you have to play will depend on the size of the company and the ability for that company to have dedicated people to fulfil those roles i.e. Product, BA, PM etc.

If I had to boil down the definition to one sentence it would be:

A Software Engineering Team Lead does whatever is required to get the team to deliver the project.

Software Engineering Manager

Depending on the size of the organisation and the organisation itself, the roles of Team Leads Managers can overlap. For instance, in a smaller company, the Software Engineering Manager may also still write code. I’ve worked in a company where that was true. This SEM also was accountable for most of the other roles that I’ve listed above in the SETL section.

In larger organisations however, there is a slightly bigger differentiator. Managers are usually more involved in the long term strategical vision for the team(s) that they run. Generally a team lead would report in to a Manager, so the manager would be a step removed from the actual code. Some companies only hire managers that were at some point In their careers engineers, others seem to worry less about the ability to write code and more about the ability to effectively integrate with the business plan and manage people. Some managers would have engineers directly reporting to them, sometime there’s a rung in the middle in the form of a team leader.

Technical Manger

This is where things get fuzzy for me. I’m going to define a TM as someone who could either run a team of software engineers, an infrastructure team or both. I’ve technically held this title, but it was the shortest role of my career as it involved procurement and other hardware related items which didn’t really interest me.

What is my job title?

I’ve held all of the above tech leadership titles throughout my career. My role at the moment is somewhere between a Software Engineering Team lead and a Software Engineer Manager. My companies somewhat conflates the two roles even though I myself do report to a Software Engineering Manager.

The predominant reason for this post is to show that tech leadership can be displayed at all levels of an engineers career. Even if you are a life long SSE that has no interest in people management, you can be a leader. As a scrum master that may not have any direct reports, you can lead and direct the team. Leadership without authority can be attained at any level as long as you display the characteristics that draw others to trusting your instructions and decisions.

As always, I’d love to get feedback on this post, so please contact me with any thoughts.

Summary FAQ

[
a

How to demonstrate technical leadership?

](#)

Category: Software Leadership Definitions

How does one demonstrate technical leadership? This can be dependent on the current level and role in which the person is. Leadership without authority is usually gained by having a proven track record of being good at your job to the point where people follow and listen to your ideas. Demonstrating tech leadership from a Tech Lead role or a manger role would be different than from an IC, and usually involves many of the same traits that you would generically expect from a leader: Trustworthiness, clear communication, leading by example, resilience, empowerment of others etc.

[
a

What are the roles of technology leaders?

](#)

Category: Software Leadership Definitions

“Technology leader” is a fairly generic term. In Software alone this can cover:

Software Engineering Manager
Software Engineering Team Lead
Principal Engineer
Senior Software Engineer

All of the above in various degrees are technology leaders. One or many of the below responsibilities could be assigned to any of the above roles:

People Management
People Development
Project Delivery
Human Resources queries (Time off, Sickness, working aboard etc)
Ensuring technical excellence
Team morale
Day to day running of the team
Mentoring
Technology advice Design responsibility
Architecture

[
a

What is the role of a Software Engineering Manager?

](#)

Category: Software Leadership Definitions

People Management and development
Human Resources related issues: Time off, Sickness etc
The direction of the team
Interacting with business counterparts
Less low level code and architect choices

[
a

What is the role of a Software Engineering Team Lead

](#)

Category: Software Leadership Definitions

Ensuring the team follows the coding patterns and styles defined
Keeping the standards of the code to a high level across all team members
Final technical decision sign off
Architecture
Mentoring team members
Day to day running of the team

[
a

What makes a great leader in Tech?

](#)

Category: Software Leadership Definitions

To be a great leader in Tech, you need to be a bit of an all rounder. You need to have good interpersonal skills that allow you to not only lead your team but also influence others in the business. A great tech leader needs to remain technical (the degree to which they need to remain technical generally relates to how high up the management chain they get). A great tech leader needs to be able to understand the business and domain they are managing within and ensure that the team is not only delivering something technically of high excellence, but solving the clients/customers needs.

The post Tech Leadership in Software Engineering appeared first on Just Another Tech Lead.

How to coach for excellence

Ben — Fri, 26 Apr 2024 13:42:55 +0000

I’ve been thinking for a while about what my first Blog post should be about. The possibilities are endless really. The life of a Tech Lead is rather varied in my experience. One of the core responsibilities and in my opinion toughest challenges that I face on a daily basis is keeping people engaged, happy and moving forwards. Computers are easy. People are hard. So I decided today to write about one of the most complex tasks in a leaders life: coaching. Coaching and mentoring are different forms of people development, but in this post we will just discuss coaching

I really enjoy working with people, I guess that’s why I moved in to a people management role rather than staying purely technical, but managing people includes having many many conversations of different types with the individual contributors we lead:

Operational Conversations
Regular 1:1s
Evaluations / Goals
Conflict Resolution
Project Updates
Career Progression

That’s just to name a few.

Not every conversation and situation requires the same type of involvement from the leader. Some conversations require mentoring, some require directive and some require coaching. I’ll leave mentorship for a future post and for now just talk about coaching.

What is coaching?

Coaching: To partner with employees to help them come to their own conclusions

This is a fairly basic definition and probably one that would be up for debate. If you asked 100 people, you’d probably get 100 different answers. But this is the definition that I’ve been taught and how I like to think of it. This in my mind differentiates coaching for mentoring as it’s about helping the person reach their own conclusions rather than taking a directive approach and telling them what to do.

Base Principals of coaching: Listening

Now this seems easy. We’ve all heard the saying, “you have two ears and one mouth, use them in that ratio”, but it really doesn’t seem to come naturally to a lot of people. I’d broadly break down people in to the following categories when it comes to listening skills:

Not even pretending to listen
Pretending to listen but thinking about what they will look like when they’re 70 years old
Listening but only really waiting to talk
Actively listening

As you go further down that list, the closer you are to becoming an effective coach.

I’d like to break down that last item a little. Active listening as defined by the never fallible source that is Wikipedia:

Active listening is being fully engaged while another person is talking to you. It is listening with the intent to understand the other person fully, rather than listening to respond. Active listening includes asking wide-eyed questions such as, “How did you feel?” or “What did you think?”

I really want to highlight this point:

It is listening with the intent to understand the other person fully, rather than listening to respond

Too many people hear the opening part of a conversation and their mind immediately links that information with something they have done in the past, something they’ve heard or something they know. Now I’m not criticising here. We all do it. The key I think is recognising that you are doing it and making a conscious effort to refocus on listening to understand, not listening to respond. It’s a very similar concept to mindfullness and breathing. You concentrates on the breaths, your mind wanders, you realise you’ve wandered and come back to the breaths. No harm, no foul.

Now if you’re naturally skeptical as I am, and think that you are a great listener, I’d suggest that you try an exercise with a trusting and willing participant. Ask them to speak about a topic of their choice for 2 minutes. Try and really listen. Really listen. Actively listen. Every time your mind wanders or thinks about something you want to say or ask, raise your hand (but let them keep speaking continuously for the whole two minutes). If you’re anything like me when I first tried this, from a distance it probably looked like I was continuously waving at a friend to their face for two minutes.

Go ahead. Do the exercise. I’ll wait.

Great, you’re back. How’d it go? Does your arm hurt from keeping it raised too long?

It’s human nature to want to fit in with people and make connections, so it makes perfect sense why we would want to let the other person know we’ve had similar thoughts and experiences – “You have have a nose! I have a nose too!”, but in the context of people development (and in general life to be honest), listening so that the person feels heard is the goal.

Asking Powerful questions

When coaching, there are two types of questions we ask and they largely fall in to the following categories:

Data Gathering	Exploratory
When	What
Where	How
Who	Why

Question Categories

I’m sure that those of you out there that have watched enough television shows with badly acted therapy sessions will go heavy on the “Why” questions, but beware! “Why” can be the most infuriating type of question to be asked. Just ask anyone who has parented a toddler and got so far through the “but why” chain of questions that they gone from “Why are we going home now” through to “but why is the universe ultimately going to end with heat death” in the space of 2 minutes. “Why’s” can be good questions, but treat them with respect.

As a coach, you want to aim for an 80/20 split with listening to speaking ratio. Remember, the idea here is that you are supposed to be getting the coachee to reach their own conclusions. With this in mind, it makes sense that you would ask more of the exploratory questions than the data gathering questions.

If you do find yourself wanting to talk, or talking too much, try to “WAIT” and think of the following:

W hy

A m

I

T alking

A great follow on question from your initial “exploratory” questions is:

…. and what else?

It keeps the coachee engaged and thinking.

The Power of the Pause

When I think of “awkward pauses”, I think of a Louis Theroux interview. Any of them really. I’m sure Louis didn’t invent the awkward pause, but I’ve never seen someone implement it so effectively.

For someone of the British persuasion, pauses are long drawn out and to be avoided at all costs. Fill the space and say anything. That’s how we are raised. For coaching though, we need to embrace the silence. Learn to bathe in the glory that is the deficiency of noise.

Pauses allow the coachee to really continue their thought pattern. To not be distracted. The silence allows them to progress with their thoughts in a natural manner.

Pausing also helps to stop “Question bombing”. We should ask one question at a time and let it be fully answered before moving on. If you find yourself mixing multiple questions at once, stop, take a breath and focus on which specific question you want to ask first. The other questions can wait until later.

The GROW model

This is a pretty common model in coaching and there’s loads of good information out there if you want to read in more detail, but here’s the TLDR;

G oal – Where do we want to be.

R eality – Where are we now.

O ptions – What are the paths to get to where we want to be

W rap up – Actionable steps to move forwards

All through this “circle of GROW” keep letting the coachee speak more and direct them where necessary using exploratory questions.

Final Thoughts

If your job were a pure coach, then what I’ve written above should be taken quite literally. For most people though, myself included, I am not a pure coach. I have deliverables, managers, customers, other team members and a myriad other reasons why I can’t let someone always come to the conclusion on their own in their own time. I was told that you should start off in a conversation coaching and move more towards directional advice if and when needed:

At some point in the future I’ll write a post on “Situational Leadership” which has some other interesting ideas on how to have conversations mentioned above, but more in a mentoring role. I think a balance between coaching and situational leadership dependent on the person, environment and situation is probably correct.

If there’s enough interest I will write up some “real life” scenarios where I put the above in to action. Sign up to my News Letter below to be notified if I post a follow up to this with these real life examples.

As always, please contact me with feedback, ideas or anything you’d like me to write about.

The post How to coach for excellence appeared first on Just Another Tech Lead.