Tag: Software Development (Page 2 of 20)

TL;DR: If you’re looking at a career in software development, it’s imperative to know that meetings are inevitable. However, the frequency and quality of said meetings vary.

Don’t let the opportunity to ask potential employers – or current employees – what meetings are like pass you by whenever you’re interviewing.

Further, if you’re in a place that you feel has too many meetings or something about them could change, don’t be afraid to bring this up when the time is right.

---

In the original article, the author writes:

There are recurring meetings scheduled on a daily or weekly basis. Most of these are not productive. The majority of them are forced by a person who is organizing them because that’s the only “work” that that person is doing.

Meetings Are Inevitable

The short answer is yes, this is true. But it’s only true in some cases; it’s not the law of companies that hire software developers. Instead, it’s based on a number of factors (some of which do include people finding their measure of productivity based on how many meetings they can schedule – but I digress).

Speaking of those few factors, these are the ones I’d like. Some of them are related, some aren’t:

• the size of the organization,
• the size of the team,
• the manager of the team,
• how the project is managed,
• and so on.

If you’ve worked in software for some amount of time, you’ve likely experienced this and/or you have your own item to add to this list.

A Word About Project Managers

One caveat I want to mention is in all of the years of working in software development, one of the things that I’ve seen – especially in a consulting or an agency-type of setting – is that a certain breed of software developers don’t enjoy having a project manager.

Assuming the project manager is worth the weight of their role and title, I’ve found having them to be liberating. It frees me, as the engineer, up from having to thing about certain things related to external factors and let’s me focus on exactly what I want to do: Write code to ship features, fix bugs, and build software.

Do not dismiss project managers. Instead, embrace them as the gatekeepers of sorts of the backlog of features and trust them to know what works best for the business. They are the liaisons between those who write code and those who will be using, or selling, the product. It lets us focus as much as possible on what you do well.

Current Status

If you don’t read anything else in this article, know that meetings do not have to take up the majority of your time when working in software development.

Currently, I work for a fully remote organization with several hundred employees. My team consists of, at the time of this writing, about seven people, and we have one standing meeting per week.

We use almost never use email (and if you’re interested in moving in this direction, I highly recommend reading A World Without Email), primarily use Asana for project and task management, and have daily stand-ups through a morning report in Slack.

Though this works really well for me, it may not work for you; however, I do find that less email and fewer meetings helps to foster a greater sense of focus.

Other Factors

It’d belabor the point to break down all of the various different reasons as to how the size of an organization, the size of a team, or how management can influence the number of meetings.

Suffice it to say that I’ve worked for large organizations, medium organizations, and small organizations and each of them had their respective way of conducting meetings. I do think that, especially in the world of enterprise software development, there are a lot of meetings.

Ultimately, I’d say that if you’re currently looking at a career in this field and you’re thinking it’s primarily going to be sitting at a desk writing code, that’s misguided (and unfortunately so).

Further, it’s a disservice many places that provide an education in software development often lack a component for what to expect when you’re actually pursuing a career in the field.

So what’s a person to do? If you have the opportunity to participate in an internship, a co-op, shadow someone in the field, pursue an apprenticeship in the field, or even just interview a number of people in the industry, I’d recommend doing any of the above.

Anything that will get you as close to the field as possible before jumping into it will be beneficial.

Ultimately What, Then?

I’m in no position to say how a business should be run nor do I have the hubris to prescribe how a team or an organization should conduct itself. I’ve shared my past and current experience and shared what I’d recommend some things to try if you’re interested in the field.

Meetings are inevitable; the number of how many you’re in isn’t necessarily so. Do what you can to find what works best for you, reasonably set your experiences, and then move forward.

Some of the definitions for incompetent:

• lacking the qualities needed for effective action
• unable to function properly
• not legally qualified
• inadequate to or unsuitable for a particular purpose

Merriam-Webster

Given this, it’s more than likely we’ve all been the incompetent one on the team at some point in our career. Depending on the nature of the work we do, it’s reasonable to assume we could all be that person whenever we join a new team.

This isn’t to discount the skill experience teaches, but each time you start a new project (greenfield or not), there’s going to be a period in which you have to learn enough about the problem domain to actually start making meaningful contributions.

All of the above is a longer way of me delaying commentary on the claim that we’ll work with incompetent people. It’s uncomfortable to discuss because we’re making a claim about peers who are not incompetent because they’re just getting started in their career or because they are the new person on the team.

They’re considered incompetent because they aren’t able to fulfill the responsibilities, obligations, and/or demands of their job because of any one point of the above definition.

So given the claim we’ll sometimes work with incompetent people and given the definition above, how true is it that we’ll sometimes work with incompetent people?

---

Will We Work With Incompetent People?

In my experience, the only time I’ve truly worked with anyone incompetent was because of a willful desire to not learn what was necessary to do the job. And by that, I mean the person had the potential to actual do what was asked of them but achieving said potential required a level of effort they were unwilling to put forth.

Therein lies how a person can become incompetent not only in the field of development but generally in any field:

• There’s a problem that needs to be solved,
• The problem exists in a domain that requires a level of discovery and/or education (and not necessarily in the academic sense),
• The person opts out of discovery and/or education,
• The person can’t solve the problem,
• And thus the person remain incompetent in their job.

Because some organizations still allow you to draw a paycheck without doing more than the bare minimum, there isn’t always a strong incentive to get better at whatever is asked.

And if this is what it means to work with incompetent people, then yes. It happens.

On Willful Incompetence

People don’t necessarily want to remain willfully incompetent, though. In my career [so far], there are plenty of times in which I would be labeled incompetent not because of my inability to ever solve the problem, but because of my inability to solve the problem at that time.

Given enough time, training, and/or information as well as enough motivation, it’s possible to move yourself out of that position and into one that enables you to get the work done.

Not only that, assuming you’re a person who is working with someone who may be currently incompetent but needs more information to become familiar with the problem domain, it’s also possible for you to be the person to help them move from one arena to the next.

In other words, if you see a need, meet it. If a colleague is unable to achieve something that you’re able to do, don’t attempt to subvert their attempt and solve it yourself.

Give them whatever help necessary to give them enough information to move forward and, assuming they’re motivated, they’ll move into the arena of being able to solve the problem.

On the Original Article

Finally, I wanted to make sure I link to the original article to see the context in which this claim was written as well as the author’s experience. In trying to summarize what’s listed here, I’d say it’s something like this:

• Dealing with incompetent colleagues in the workplace can be frustrating and time-consuming, creating a toxic environment that affects productivity and deadlines.
• Working with such individuals can lead to significant delays, ultimately costing companies both money and resources.
• The frustration and challenges posed by incompetent colleagues can prompt individuals to spend considerable time strategizing ways to navigate around their lack of competence.
• In certain situations, individuals may lack the complete context behind someone’s performance issues. There are instances where individuals struggle to perform well due to an overwhelming workload, juggling responsibilities meant for two people and hindering their ability to fulfill their job adequately.

So, yes, there are differences in what he’s experienced versus me. I’m not arguing his claim (any more than I’ve done so in the past articles). I’m just stating my observations, experiences, and ideas on how to mitigate the situation.

Final Outcomes

Ultimately, I find that one of two outcomes will happen:

• The person will be motivated and needs more information to get started.
• The personal lacks motivation and desire to do more than the minimum amount of work. This will be a hindrance, but there’s very little that can be done about it.

Whatever the case: Don’t dismiss incompetence on its face. Perhaps the person needs more help. And in any case, good luck.

If you’re around my age or have been in the industry since the early 2000s, you likely think of the phrase “clean code” being synonymous with the book by the same name written by Uncle Bob (or Robert Martin).

From the description of the book:

[Robert Martin] has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of software craftsman, and make you a better programmer―but only if you work at it.

Clean Code Description

There’s a long history behind what Uncle Bob was trying to do with the software craftsmanship movement (and I don’t think his ideas were bad, for whatever it’s worth). And this book, along with a few others, helped to foster large swaths of developers to begin implementing certain practices in their day-to-day work.

This book, the author, and what it espouses is not without criticism and it seemed to get stronger the longer the book has been out. But regardless of how many practices are taught in a book – or lecture or podcast or presentation – there is always at least something to take away from it.

And though there are plenty of things in Clean Code that are tough to put into practice or aren’t always feasible to do so, that doesn’t mean some of it can’t be done.

This doesn’t refute or support the statement in the original article though, does it? Specifically, said article claims: “Nobody gives a f*** about your clean code.”

Is that true?

---

Who Cares About Clean Code?

A Little Bit of History (or “Back in the day…”)

When I started my first job out of college, we were used a tool called BitKeeper for version control. It’s since been discontinued. Here’s the thing about BitKeeper though: It was only for committing code. There were no other associated tools like we’ve come to expect with GitHub (such as PRs, issues, project management, wikis, etc.).

This meant that all code reviews – even if we were pair programming on a project – requested code reviews via email. So before we committed any code that would go out to staging, it needed to be reviewed by a team (of approximately seven people – they were small teams :) and it had to be done via email.

The idea of doing code reviews via email seems silly now, but that’s how it was done. Regardless, the point is we were still doing code reviews.

And this is where the concept of clean code is relevant.

At some level, it was always expected that we would be writing readable code. This isn’t necessarily the same as clean code because readable code can include a function that’s dozens of lines long and does more than one thing, but it gets the work done (whatever the work may be).

If the project allowed for it, then cleaner code and strong architecture was usually expected and if basic principles weren’t put in place then it would be brought up during a code review.

And this is where it’s important to ask: Does anyone care about clean code? Often times, it’s deadlines that matter (or the amount of time it takes to deliver a working solution).

A Hierarchy of What Matters in Software

Since having a working solution is what provides value to a user then whether or not it’s built following a particular paradigm or employing a set of principles that make for cleaner more maintainable code will always take a backseat.

If there’s a hierarchy of what’s often expected out of code, it’s something like this:

1. It solves the problem (it works),
2. It’s bug free (in so far as it’s measurable),
3. It can be easily patched if a bug is caught,
4. It’s commented so fellow developers know what’s happening if they have to jump into the fray to work on it,
5. It follows whatever coding standard the organization implements,
6. It follows the principles of Clean Code.

There are probably a lot more but the point I’m making is that the author is right: Clean code doesn’t matter as much as delivering a working solution.

If writing clean code delays shipping a solution then the natural consequence is you’re punting value for the customer over something they aren’t even aware exists.

The user doesn’t know how the codebase looks. The user just sees what features that product is offering. So don’t get overly attached to your clean and elegant code. Focus on shipping the feature on time and bug-free.

10 hard-to-swallow truths they won’t tell you about software engineer job

With all of that said, this is not an excuse not to attempt to write clean code, refactor when possible, or provide well-architected solutions.

Then How Can We Integrate Clean Code?

Whenever code is submitted for a code review, it’s likely that you’ll get feedback that is something like:

• Maybe change [this particular line] to be a bit more readable such as removing the nested ternary operator,
• Add a clause [to this function] so you’re checking to make sure something is readable or writeable before working with it,
• Consider adding a guard clause at the top of the function,
• If time allows, maybe create a base class and then subclass it so we don’t have some much duplicate functionality,
• …and so on.

There are a lot of common suggestions here – so common that these are the ones that are at the top of my mind from code reviews I’ve received (and given). But did you catch the point about creating a base class? This is one of those pieces of feedback that appeals to DRY and though it’s something that would make the architecture more maintainable, it will also delay development more than the rest.

At this point, it’s likely going to be hard to implement that unless there’s enough time in the project. The other pieces of feedback will take priority.

When it comes to employing clean code in my day-to-day, I’ve found it most effective to start adding little things in as I have the chance. It’s a lot like compound interest – over time, the value adds up.

And then when you’re used to employing the small things all along, employing more strategic decisions gets easier because you’re already training your mind to think in terms of these strategies. After a long enough time of moving in this direction, you should be able to integrate writing clean code into your workflow all the while meeting the necessary deadlines.

This doesn’t mean you’re going to be employing every principle. That’s tough. But if you can start small and make those contributions over time all the while gradually training your thinking to fall in line with the principles of clean code, then it becomes the primary way in which you’ll write code.

No, you won’t always be able to do it. No, people generally won’t care about it: they’ll know what you’ve done when they see it but don’t expect praise for it. And though you may get some feedback on how to improve the code, there likely won’t be time to do so and you’ll have to earmark the suggestion and employ it in another project.

---

For many, it’s more popular to talk about clean code than it is to employ it. It’s more fun to talk about code than it is to write it. And it’s more fun to ship code than it is to refactor it.

So, yeah, most people aren’t going to care about your clean code. But that doesn’t mean you shouldn’t aspire to write it. I’m 16 years into my career and still working on employing new strategies with just about every project I write. I enjoy it even if code reviews don’t care about it.

And that’s because I know, ultimately, it’s going to make me a better engineer and it’s going to make the software more maintainable over time. Sure, it takes time to get there, but such is the case with just about anything worth doing.