Forem: Jason C. McDonald

Searching Outside the Box (OTB Ep 9: Anna Greene-Hicks)

Jason C. McDonald — Fri, 13 Dec 2024 14:00:00 +0000

Anna Greene-Hicks (Information Technology Instructor) shares how she took her job search offline, thought outside the box, and found her next adventure.

Watch on YouTube

Networking Your Next Role (OTB Ep 8: Marlon Peseke)

Jason C. McDonald — Fri, 06 Dec 2024 14:00:00 +0000

Marlon Peseke (Software Engineer) talks about his path from teaching to boot camp to web accessibility development. He shares his insights about networking to land a new role.

Navigating Expectations (OTB Ep 7: JJ Brenner)

Jason C. McDonald — Fri, 22 Nov 2024 14:00:00 +0000

JJ Brenner (Software Engineer) shares his tips on navigating the expectations and social games of job hunting and interviews.

Challenging Bias in Hiring (OTB Ep 6: Todd Lucas)

Jason C. McDonald — Fri, 15 Nov 2024 14:00:00 +0000

Todd Lucas (Project Manager) shares his journey overcoming the assumptions of hiring managers, and the sometimes surprising results of calling out biases.

Transcending the Niche (OTB Ep 5: Paul Hardin)

Jason C. McDonald — Fri, 08 Nov 2024 14:00:00 +0000

Paul Hardin (Security Consultant) discusses shifting specialties and breaking out of niches to land a new role.

Taking on New Challenges (OTB Ep 4: Ned Batchelder)

Jason C. McDonald — Fri, 01 Nov 2024 13:00:00 +0000

Ned Batchelder (Software Engineer) shares the challenges of finding and taking on a new adventure late in one's career.

Leveraging Job Hopping (OTB Ep 3: Abraham Vanderpool)

Jason C. McDonald — Wed, 30 Oct 2024 05:00:00 +0000

Abraham Vanderpool (Product Owner) digs into how he's used his experience across multiple jobs and industries to improve his desirability as a candidate.

Overcoming Imposter Syndrome (OTB Ep 2: Monica Ayhens-Madon)

Jason C. McDonald — Mon, 28 Oct 2024 05:00:00 +0000

Monica Ayhens-Madon (Community and Marketing Coordinator) shares how she overcame imposter syndrome to land her next role.

Finding the Right Job (OTB Ep 1: Jennifer Rorex)

Jason C. McDonald — Fri, 25 Oct 2024 15:05:17 +0000

Jennifer Rorex (HR Generalist) shares her unexpected journey to finding, not just any job, but the right job.

Introducing "On The Board"

Jason C. McDonald — Fri, 25 Oct 2024 14:58:42 +0000

These are unprecedented times in the tech market. It seems harder than ever to find a job, made worse by the constant stream of conflicting and dubious advice from recruiters, influencers, paid resume writers, and career coaches.

Even so, people ARE finding new roles every day. In the new podcast series "On The Board", @michaeltharrington and I interview the folks who have actually landed new roles in the crazy 2023-24 job market. Learn what actually works, and what doesn't, from real experiences.

I'll also be sharing the episodes here on DEV.

How To Estimate Software Development Effort

Jason C. McDonald — Thu, 07 Sep 2023 14:30:05 +0000

Estimation — the one loose thread in the tapestry of Agile. There is plenty of material describing what doesn’t work, but despite our best efforts as an industry, none of the solutions thus far have seemed to work. Traditionally, there has been an implicit lack of consensus on the purpose of software estimation. What precisely are we measuring, and thus estimating? Is it the time it will take to complete a task, the date when we can ship, or the cost of the development effort? The answer usually depends on whom you ask.

A Trip to the Store

Consider a shopping trip to the grocery store in preparation for a party. You have a list of items and a budget. Notice what we don’t consider: the number of transactions, the size of the shopping cart, or the number of shoppers. Why? Our limiting factor is our budget, and our goal is to purchase everything on the list. Adding more shoppers or using larger shopping carts will not change that budget.

Once you have identified your limiting factor, you can either take a predictive or an adaptive approach to planning your shopping trip.

The predictive approach is to try to guess how much all the items on your list are going to cost. Assuming you don’t have the option of looking up the prices online, you’re going to have to make your best guess using knowledge of prior shopping trips, maybe some old grocery receipts, and awareness of how prices have changed recently.

The adaptive approach is to write a list of the items you want to purchase, and determine your budget for the trip. That budget is normally dictated by external factors, and not by the items on your list. You would probably also prioritize your shopping list, so if you find your budget isn’t sufficient to cover everything, you can easily determine what to skip.

Often, you’d take some sort of hybrid approach that combines both techniques. Knowledge of prior shopping trips and market rates may help you write a realistic shopping list, and then you can iterate on this list once you’re at the store.

Which approach makes more sense for your shopping trip? It depends on the situation. Regardless, if you don’t know your budget, none of these techniques will work!

What Do We Measure?

In software estimation, we deal with finite resources as well, such as financial budgets and time constraints. Starting our thinking from these is dangerous, however, because neither directly correlates to how many items on a list of software development goals we can complete.

The real limiting factor in software development is Developer Energy. Human beings have a limited amount of cognitive energy each day and each week, and once that is exhausted, the quality of their work diminishes significantly. (This is a major reason why the adage “never ship on Friday” exists; errors are more likely at the end of the workweek.) One cannot overcome this limit by simply demanding overtime or paying additional money

That is not to say that time and money cannot be used to increase Developer Energy. You may eliminate unnecessary meetings to free up Developer hours, or add additional headcount (while taking Brooks’s Law into account.) These are merely ways of expanding your “energy budget,” but Developer Energy is still the limiting factor. Once a Developer is “out of gas”, you’re not getting any more work out of them until they recharge in whatever manner they need to.

Once we have identified the limiting factor as Developer Energy, we can begin the task of software estimation. Unlike traditional story pointing, the Quantified Tasks methodology actually provides a technique for repeatably measuring, tracking, and estimating the developer energy budget.

How Do We Measure

The problem with traditional Agile Story Points is that they only indirectly measure the Developer Energy required. It’s a bit like going to the store with no clear budget, but a vague sense that the ice cream will cost twice as much as the coleslaw. What’s worse, because the amount of effort a Story Point represents varies from team to team and project to project, you have no frame of reference when planning effort on a brand-new project. It’s as if every grocery store lists prices in its own original currency.

By contrast, Energy Points in Quantified Tasks are an objective, repeatable unit of Developer effort. Instead of translating an arbitrary assessment into (say) a Fibonacci number, Energy Points are calculated from three objective 1-5 scores:

Distance: raw effort if you knew everything about the task,
Friction: available resources to inform the task, or the lack thereof, and
Relativity: how much uncertainty exists in the task.

Any two Developers may have different ideas about how “big” or “hard” a task is, depending on their experience level and other factors, but it is fairly easy for everyone to agree on a score for each of these three measures.

Energy Points are calculated via the formula (Distance + Friction) * Relativity. This estimate is thus defensible, as each of the three factors are objective, and it bears the authority of team consensus. Not only this, but because it is based on three predefined, fixed metrics, the Energy Points estimate can be compared directly to any other task from any other project or team using Quantified Tasks.

Energy Points thus represents how much Developer Energy is needed to complete the task.

Budgeting Developer Energy

Given Energy Point estimates on every task, we are now only missing one piece of information: how much Developer Energy do we have? What is our budget?

Every Developer is a unique individual. They will have different strengths, weaknesses, and experiences. Thus, for a Developer who is brand new to Quantified Tasks, it will be difficult to guess how many Energy Points they can complete in a sprint. However, after only one or two sprints, each Developer will begin to form an understanding of how much work they can complete under the circumstances.

For example, as a Principal Software Engineer in Python, I found I could complete an average of 25 Energy Points per sprint. It did not matter what the project was — as long as it was a Python-based stack, that estimate held true. If I was not proficient in the language, I could complete about 10-15 Energy Points in a sprint. Thus, I was able to select work for myself during Sprint Planning, and nearly always complete that work by the end of the sprint. (Estimates are exactly that — estimates.)

What’s further, Developers can use Distance, Friction, and Relativity to select work appropriate to their experience level. Someone brand new to a language should probably avoid taking on a high-Friction task, while someone who is more senior in that language should try to leave some of the easier work to the less experienced members of the team. Although two tasks with the same Energy Point estimate require roughly the same amount of energy, different Developers can handle different styles and cadences of effort.

As a Developer begins to track their Personal Velocity (the average Energy Points completed per sprint), it will become easier to set realistic goals for sprints and releases.

Measuring Developer Productivity

Energy Points not only allow you to estimate effort, but they can also serve as a reliable metric of how much work was completed. As long as the Quantified Tasks methodology is applied correctly by the team, and scores are updated as more information is learned, Personal and Team Velocity become good representations of Developer productivity.

There are a few things to be aware of with this, however, including:

Each Developer has a unique, fixed energy budget. This can be further impaired by external factors. Use Velocity as an indicator to trigger further inquiry, never a goal to be met.
Be wary of comparing Personal Velocity across Developers. No two people are identical, even if they have the same seniority and experience level.

If you want to use Quantified Tasks to measure Developer Productivity, please see Measuring Developer Productivity...For Real!.

Getting Started with Quantified Tasks

If you want to get started using Quantified Tasks with your team or company, check out the Overview on the official website: https://www.quantifiedtasks.org/p/overview

Training Juniors Remotely Is Possible. Here's How.

Jason C. McDonald — Mon, 28 Aug 2023 16:01:31 +0000

Day after day, the call goes out: "We must return to office! Remote work is harming productivity!" The claims behind this urging include one that often makes even the most determined remote worker pause and nod: juniors must have an office environment in which to learn their jobs. But is this true?

Few will dispute that junior employees are among those most negatively impacted by the remote-first model necessitated by the pandemic. After all, most productive remote workers had already forged their professional networks and built their skills in a business world that was almost entirely in-person. Entry-level employees typically lack both, and thus struggle in ways their more senior counterparts cannot comprehend. But before we declare remote-first a failed experiment and rush back to our cubicles, we need to take a hard look at why juniors struggle to network and train in a remote world.

For over a decade, I've been running one of the world's first remote software engineering internships. Our graduates have gone on to successful careers, many as senior engineers and managers, and quite a few at in-person jobs. For many, the internship was the only entry-level position they ever held.

My time as an internship manager has taught me that the answers to the problems juniors face in a remote environment are more nuanced than merely restoring in-person interaction.

Key 1: Communicate Deliberately

In an office setting, juniors absorb information through observation. So-called "fifth man" assignments provide opportunities to sit in on work sessions and see how more senior employees handle different situations. This is an appealing arrangement to employers because it costs very little, and the other employees seldom need to do more than answer an occasional question. Sometimes, the observing junior may even make a valuable contribution!

...intense isolation can become a real problem in remote-first work, especially for juniors. The solution here is to deliberately create regular opportunities for interaction.

In a remote-first environment, opportunities for this sort of passive training-by-osmosis technique are virtually nonexistent. Most work is done asynchronously, or else through ad hoc interactions like Slack Huddles or JetBrains Code With Me sessions. A person can easily spend an entire week without hearing another human voice, at least outside daily meetings. As a result, intense isolation can become a real problem in remote-first work, especially for juniors.

The solution here is to deliberately create regular opportunities for interaction. (Note: this is not justification to book more meetings.) Here are a few techniques I've seen first hand over the years, including some I've implemented in the internship program:

Regular collaborative sessions, such as mandatory pair and mob programming. Woody Zuill has an excellent talk on how powerful daily mob programming is, and why your team should try it. I can personally vouch for its effectiveness, both for productivity and leveling up everyone's skills. Even on the most dysfunctional team I ever worked on (as a mere developer), it was a potent technique.
Tools like Gather Town to encourage more ad hoc group interaction. One team I led used this tool daily for nearly a year, and the frequency and quality of our interactions were on par with an in-person office.
"Shared space" sessions, where everyone joins a video call while doing quiet solo work. Similar to Gather Town, this increases natural opportunities for observation and interaction.
Daily shared work journals. When the internship program went international, it became difficult to schedule times for everyone to be present concurrently. Mandating daily work journaling (e.g. as a replacement for stand-up), and commenting on each other's journals, strengthened work relationships and created countless mentorship and co-learning opportunities.

If you're using Agile in any fashion, then Sprint Retrospectives are your best tool to figure out what collaboration patterns are working for your team, and which are not. Adjust accordingly, but never make regular collaboration optional. I recommend that between 30% and 50% of the work week should involve some form of active or passive collaboration (such as a "shared space" session).

Juniors in any field possess a special skill: they don't know the "right" way to do things, so they're more likely than a senior to invent novel solutions and spot subtle errors.

Within this context, ensure your staff is including the juniors! Team members should offer to let them observe or participate in collaborative sessions whenever practical. One may think that pair programming with a junior developer sounds like an awful waste of time, but I have lost track of the number of times my interns have taught me something or caught some error or edge case I'd completely overlooked. Juniors in any field possess a special skill: they don't know the "right" way to do things, so they're more likely than a senior to invent novel solutions and spot subtle errors.

Key 2: Prepare Your Staff

Bringing juniors onto a team should never be taken lightly. You are asking the rest of your team members to add "mentorship" to their effective job description, and as with any expansion of responsibilities, you must communicate expectations, requirements, and policies. This is doubly true in a virtual environment, where anything short of deliberate engagement results in isolation.

Let the mentee devise their own solutions....Only step in when they ask you to, or when they're about to walk off a steep cliff. It is easier for someone to dig themselves out of a hole they dug for themselves, rather than a hole you dug for them.

There are a few principles I recommend for anyone in a mentorship role, whether formal or informal:

Ask more questions than you give answers. Try to lead the mentee to discover the answer themselves.
Demonstrate more than explain.
Be honest with your shortcomings. Tell the mentee about the time you took down the production server! Normalize making, owning, and fixing mistakes.
Offer to research with the mentee, even if you know the answer. No one is born knowing how to properly use Google, ChatGPT, or Stack Overflow.
When you explain something, always have the mentee explain it back to you.
Let the mentee devise their own solutions, even if they're different from yours. Only step in when they ask you to, or when they're about to walk off a steep cliff (e.g. delete the production server, cause the project to overrun deadline, etc.) It is easier for someone to dig themselves out of a hole they dug for themselves, rather than a hole you dug for them.

On the whole, one always learns more from making and fixing their own mistakes than by any other means.

Key 3: Onboard Well

Naturally, none of my interns were ready for this kind of responsibility on day one. Every junior starts the same way: excited, overwhelmed, and with rare exception, scared stiff.

Excellent documenation is essential for a smooth onboarding process, and this goes for all employees! Every team should have a routinely maintained step-by-step guide to setting up and getting started with work. For developers, this guide should take anyone from zero to merging code that meets the team's standards and definition of done. Similarly, all standards, policies, procedures, and workflows should be documented in a standardized location. When this documentation is in place, onboarding occurs within 1-2 days; without it, it can take weeks before a new team member is independently delivering value.

(Pro tip: ask each onboarding employee to immediately report any errors or confusion to someone who can correct the documentation. Onboarding documentation should be self-contained and repeatable for juniors and seniors alike; no prior knowledge or external guidance should be needed, except where explicitly hyperlinked.)

For junior developers, the first task I assign is usually a review of a more senior developer's code....all the interns who started with code review were competent in the language within a month.

On day one, a junior should be paired with a mentor. In most cases, their first face-to-face interaction with that mentor should be the same day. However, juniors should also meet their mentor's manager, and should know how to contact them, just in case there are conflicts or concerns.

There are two things you do not want to do on the first week: do NOT leave them to their own devices, and do NOT assign them career training materials. You are running a business, not a school. There is probably some good training material you should provide later -- in the internship, I had two books that were required reading -- but you want to get them doing actual work as soon as possible. Make time later for "continuous career training," and ensure it's something you provide to your whole team, not just your juniors.

For junior developers, the first task I assign is usually a review of a more senior developer's code. I instruct juniors to work through it slowly, looking up any syntax or pattern that is unfamiliar, and asking the code author to explain anything they still don't understand. I am always amazed at the effect this simple task has on a junior's learning path. Most interns came into the internship program with no knowledge of C++, our primary language, but all the interns who started with code review were competent in the language within a month.

Key 4: Check In Regularly

Juniors in particular must never be left to guide themselves. Even the most self-motivated entry-level worker lacks the expertise to recognize flaws and inefficiencies in their techniques in a reasonable time frame.

...research is a treacherous rabbit hole, especially for juniors. Encourage them to timebox their research within an hour or less before asking for help.

At minimum, every junior should have an assigned mentor, with whom they meet at least once a week over video chat or face-to-face. I emphasize one-on-one, as it is often difficult to admit to gaps in knowledge or skill in front of a group, even peers.

It is crucial that the mentor asks plenty of open-ended questions. In particular, I recommend the following:

What went well this week?
What challenges did you face?
What have you learned this week?
What are you trying to solve right now?
How can I/we best support you this coming week?

In general, juniors will seldom voluntarily admit to not understanding something. Nearly every intern I've ever trained has felt compelled to exhaust all possible avenues of self-guided research and experimentation, up to the point of completing entire Udemy courses, before asking for help.

While it's an important skill to find one's own answers, research is a treacherous rabbit hole, especially for juniors. Encourage them to timebox their research within an hour or less -- I usually suggest 30 minutes -- before asking someone for help.

Finally, don't assume that juniors are getting everything they need out of their working relationship with their mentor. The manager should also check in with the junior and mentor separately, at least once a month. Find out how the junior is feeling about their overall experience with their mentor and team, and if it aligns with their needs and career goals. Determine if the mentor has identified any opportunities for growth, or any potential challenges or concerns.

Key 5: Assign Real Responsibility

One mistake I see many organizations make with their interns and entry-level employees is to assign them tasks with little or no importance to the project. Juniors aren't stupid: they know when they are expected to fail, and will respond with timidity, thereby capping their professional growth.

I had to entrust senior-level tasks to the interns. What took me by surprise was that, with rare exception, interns rose to the occasion and completed the work to the standards I'd expect from experienced developers.

In running the internship program, my development teams consisted largely or entirely of interns. This forced me into a position some would consider ill-advised: I had to entrust senior-level tasks to the interns. What took me by surprise was that, with rare exception, interns rose to the occasion and completed the work to the standards I'd expect from experienced developers. Yes, I had to provide a bit more initial guidance than I might with a senior developer, but the results were nearly always superb. I had interns designing and implementing critical pieces of software architecture, building and maintaining DevOps pipelines, debugging esoteric bugs, and even leading project teams. These weren't all college seniors and graduates either; we had a mix of students, boot camp grads, self-taught hobbyists, and second-career learners from all over the world.

In assigning real responsibility to juniors, ensure mentors check in regularly to spot problems and ensure they don't veer off the path. Just as important, continually gauge the junior's interests and confidence level. If they are bored with a task, encourage them to finish it to their best ability anyway (because not all tasks at work are fun!), and then reevaluate what sorts of tasks to assign them. This is a prime season in any professional's career to discover their strengths and weaknesses. By encouraging this experimentation and exploration, you will both give and receive the most value.

Things To Watch Out For

In all the time I've spent training interns and mentoring developers, I've learned three warning signs that an individual will not do well professionally without intervention.

Juniors who repeatedly refuse to seek assistance when stuck, or who actively avoid collaboration, virtually never succeed. You must never allow collaboration to be optional!

1. Lack of attention to detail.

This can take the form of skimming instead of reading, a pattern of sloppy mistakes, or routine disregard of policies, procedures, standards, or workflows.

Mentors should explain the importance of slowing down and paying attention. Encourage note-taking and effective reading and listening strategies as appropriate.

However, be mindful of neurodiversity here; if a junior expresses routine difficulties with focus or attention, encourage them to seek out appropriate resources and professional guidance. Accessibility and Disability Employee Resource Groups are crucial here!

2. Poor time and priority management.

Watch out for juniors who are frequently late for, missing, or "forgetting" appointments and deadlines, even with excuses. Notice when they repeatedly disregard communicated priorities, such as completing low-priority tasks over high-priority ones. Inversely, notice when they are working too much, failing to take breaks, or are hyperfocusing for hours on end.

In this situation, mentors should introduce time and task organization techniques, such as Pomodoro Technique, Bullet Journaling, and Getting Things Done. Once again, be mindful of neurodiversity here.

3. Isolation, or "Lone-Wolfing" (and Psychological Safety).

Juniors who repeatedly refuse to seek assistance when stuck, or who actively avoid collaboration, virtually never succeed. This is where it is absolutely essential that mentors maintain regular lines of communication with their mentees, and teams deliberately include juniors in their day-to-day work. You must never allow collaboration to be optional!

Address problems at the scope they occur.

However, if a junior is avoiding interaction, don't assume they're doing so out of a desire to go it alone. Psychological safety is absolutely essential! You must carefully monitor your team's communication patterns, and swiftly address any forms of harassment, discrimination, destructive criticism, and hazing. Juniors should never have to "earn their place", regardless of who they are or where they come from. They are a full-fledged member of the team from day one, and must be treated as such.

If you notice anyone, junior or otherwise, is avoiding collaboration or communication, have a gentle one-on-one conversation with them. Draw out their concerns and fears, and do your best to address them.

To that aim, address problems at the scope they occur. If an employee makes inappropriate jokes in team meetings, call them to account in the same team meetings. If someone is being harassed on a Slack channel, address the harassment on the Slack channel. If discriminatory remarks are made in private, address it in private (with or without the victim present, as appropriate.) This is important for three reasons:

It tells the victim that their safety is a priority.
It tells observers that the problem behavior is not acceptable; you are both discouraging similar behavior and empowering others to intervene in future situations.
It puts pressure on the offender not to repeat the offense, by sending a clear message that they will not be protected from the consequences.

In addition to psychological safety, you must consider if there are neurodiversity-related issues leading the junior to isolate. If this is the case, you should consult with them and HR to determine if any accomodations can be put into place to address the issue.

Once you've addressed or ruled out any of the above, if the junior continues to isolate, you may need to utilize a formal Performance Improvement Plan to tackle the problem.

Conclusion

Juniors can make incredible additions to your team. They often draw out the best from other team members, and their eagerness and inexperience helps keep everyone out of the dreadful rut of "we've always done it this way."

On a remote-first team, juniors additionally expose flaws in communication and collaboration patterns. When their success is made a priority, the entire team will discover new and better ways of working remotely.

In this new era, we have an incredible opportunity to rethink how we approach work. Today's juniors are tomorrow's seniors. The patterns we establish now will forever change the professional world. The companies that adapt to these new challenges will be the winners, attracting the next crop of talent entering the workforce.