Author: Tom (Page 6 of 427)

It’s Hard to Estimate Writing Code (And Always Will Be)

January 18, 2024 / Tom

There’s an old – relatively speaking of course – quote that says:

There are only two hard things in Computer Science: cache invalidation and naming things.
Phil Karlton

Though I think coming up with estimates for completing a task may be a close third (or at least somewhere pretty high on the list).

A computer programmer, stressed, as she tries to come up with a clever name for a variable.

Having worked as a contractor, in an agency, and in product work, I can say though there may be small variations on how estimates are handled, the basics are the same such that it goes something like this:

A task is a unit of work to be completed as part of a larger project,
Each task has a start date,
Developers are asked to estimate how long it will take to complete said task.

Here’s the thing: There’s usually an ideal goal in mind for when the task should be a completed. If it can be completed in the ideal range, great; if not, then it has to be scoped so that it fits within a reasonable range. Any work left over moves into another phase of work.

So from the outset of the task, we’re expected to estimate how long it will take to complete the the work even though it’s the period in which we know the least amount the problem domain.

This is why estimates are hard.

There are a few caveats to this that I’ll get to in just a moment, but I want to point out that this is simply part of the software development process. I’d say that it’s almost law at this point (but there are plenty of shops and developers that always surprise us, so I perhaps it’s just an unwritten rule that can be broken).

Suffice it to say, estimating tasks is an inevitable part of the job of a developer. As such, it helps to know what it actually entails and it helps to have some suggestions on how accurately estimate a task.

How to Estimate Writing Code

Yet another programmer staring at a kanban boarding trying to figure out if the next task can fit in the sprint.

Depending on which type of software development lifecycle you and/or your team use, the way tasks are estimated may be different but they are different nonetheless.

The Waterfall Method usually has phases each with its own plan that cascade down into the next phase.
An Agile Method will use something like sprints that then will use some type of measurement (perhaps story points or days or hours) to estimate how long a task will take and then a sprint will only consist of a set number of story points. If a task exceeds that maximum amount of points, it’s either re-scoped or moved to the next sprint.
The Iterative Model works something like creating an MVP and then slowly working to improve upon the base (though how long each team wants to spend on working up from the MVP varies).
And so on.

There are many models that exist within software development but the one thing they all have in common is this:

Everything that needs to be built can be reduced to a task and a task can be measured in a unit relative to the project.
Whoever your stakeholders may be have an ideal number for the units they think are reasonable and they will often vary from what you, as a developer, think is reasonable.

This is where I whole-heartedly agree with the original article. It states:

Business revolves around numbers. Every project has its cost, and to calculate the cost, management needs to estimate how long it will take to build a certain feature

Your boss counting his money from all of the time spent by properly estimating taxes.

So, as far as this article is concerned, this leaves two questions:

What are the caveats mentioned earlier in the article?
How do we accurately determine estimates?

Caveats

Whenever I think of someone responsible for building software, I think of people who are working with a consistent set of tools and a tech stack with which they know well.

For some, this may be the Microsoft stack of SQL Server, .NET, and whatever frontend tooling they are using (perhaps its a native GUI or a webpage). For others, this may be MySQL, PHP, and something to render user interface components within a browser.

And even each of those have their own subset of technologies they use. My point, though, is that developers usually have a set of technologies they use to build the solutions for which they are tasked. These technologies are used day-to-day in their job and are primarily how they build their solutions. (This is why we hear if someone is a “Microsoft shop” or a “Laravel shop” or whatever term you want to use.)

This is a software development shop that looks exactly like where we all work, right?

The point of discussing estimates is not to get bogged down into what’s used to build the solution at hand; instead, it’s something more along the lines of “given the tools we typically use, how long will it take to build this solution.”

So the primary caveat is that I’m assuming you consistently work with the same technology stack. This matters because the longer you work with it, the easier certain problems can be solved.

But if it was consistently consist, we wouldn’t be discussing estimates, would we?

Determining Estimates

As I mentioned earlier, we know the least about the problem space from the outset of the project. Yet this is when we’re tasked with estimating how long it’s going to take to complete a task.

Since we don’t know what we don’t know when we don’t know, we absolutely have to be generous when estimating our tasks.

Later, when you start to work on that feature, you encounter many problems that you weren’t aware of when you gave time estimates. Then you need to compensate for the wasted and hope not to break the deadline.

Three scenarios can play out from this. In no particular order:

You may not finish the task within the allotted time.
You finish the task exactly with what time was estimated.
You finish ahead of schedule.

In each of these cases, there’s always more than can be done. But a good rule of them, as written in the linked article:

If I need to deliver some feature, and I think it will take 2 days, I add roughly 40% more time to it, just to be safe. So, in this case, the estimate will be 3 days. Later, if I am done in 2 days, I can just deliver it earlier.

In other words, don’t over estimate yourself and even when you fill confident, estimate more than you think you will need. This will help build out confidence both for you, your team (as well as your project manager, if you have one), and the business.

Your manager terrified of the estimates you’ve given.

If you don’t estimate properly every now and then, that’s okay; but always err on the side of liberal estimates. You absolutely need to account for the things for which you aren’t even aware yet.

Conclusion

I’d be remiss if I didn’t clarify what happens in the three points above for how three scenarios of estimation play out so I’ll do that here (and recap them, too).

If you don’t finish the task in the allotted time, it may be punted to the next unit of work, you may have the ability to ship part of the work while creating a new task in the next phase of work.
If you finish the task exactly with what time was estimated then you’ve estimated well (was it a fluke?) and the feature can ship when expected.
You finish ahead of schedule then you’re getting good at estimating (assuming it wasn’t also a fluke :) and you’ll be able to pick up another task to work on even if it can’t ship in this phase of work.

Ultimately, the longer I’ve been in the industry and using generally the same tech stack, the more I continue believe in the idea of overestimating my tasks. This allows for exploration of the problem domain and the ability to develop a full, working solution within the phase. In other words, if I was to give my past self advice, this is what I would’ve liked to have had on hand.

It’s helpful to remember Parkinson’s Law:

Parkinson’s law is the observation that the duration of public administration, bureaucracy and officialdom expands to fill its allotted time span, regardless of the amount of work to be done.

This is something you may occasionally hear in software development circles. And though it didn’t originally apply to it, it sometimes happens that way. Thus, part of our job is to make sure that we don’t fall to trap to this and that we properly estimate writing code and stick to it.

This part is oftentimes more of an aspect of self discipline than anything else.

If you’re a veteran – regardless of what technologies you use – you probably already have a strategy in place to help with estimates.

But if not or if you’re new to the field, perhaps this will help.

Identifying and Registering Anonymous Functions in WordPress

January 5, 2024 / Tom

Originally, this article started as an explanation for how to remove anonymous functions registered with WordPress. As I started writing, it became obvious it’s helpful to understand what PHP does behind-the-scenes when anonymous functions are registered.

This dude clearly doesn’t understand anonymous functions. The eyes give it away.

Furthermore, this helps give a deeper understanding as to why registered anonymous functions can be problematic and how we can deal with them on a technical level.

Finally, it’s worth noting that I don’t take a hard stance on if anonymous functions should never be used or not. There’s a time and a place where it makes sense, and there’s a time and a place where it doesn’t need to be done. That’s a topic to cover in the future, though.

I’ve mentioned this before, but I’m not in the business of sharing the author of any given tweet [anymore] for the sake of how X/Twitter mobs can behave. Besides, it’s the content of the tweet that warrants a discussion, not the person who said it.

Some time ago, I saw this come across my feed:

I do wish developers would stop using WordPress hooks with (what I think are called) anonymous functions […].

They are very hard if not impossible to unhook.

As mentioned, the how to deregister anonymous functions and the “whether or not this is a good idea” are topics for another post. For now, I want to share what happens whenever an anonymous function is registered with a hook in WordPress.

Named Functions in WordPress and PHP

Brainstorming names for named functions. Naming things is hard.

First, an example:

add_action('admin_init', 'tmAddBackgroundColor');
function tmAddBackgroundColor()
{
    echo '<style>
            body {
                background-color: #f3f3f3;
            }
          </style>';
}

In the code above, we’re using a named function – as opposed to an anonymous function – to do the following:

add_action('admin_init', 'tmAddBackgroundColor') hooks the tmAddBackgroundColor function to the admin_init action. It tells WordPress to execute the specified function when the admin area is initialized.
The actual function adds a custom CSS style to the admin area.

If I was a third-party developer who wanted to remove this functionality, then I’d locate the function and invoke the following call somewhere in my code:

remove_action('admin_init', 'tmAddBackgroundColor');

This is an obvious benefit to named functions. Even if the function is located in a different namespace, it’s possible to remove the action by prefixing the function name with the name of the namespace.

What happens with anonymous functions, though?

Anonymous Functions in WordPress and PHP

You don’t have to name an anonymous function. You might as well just stare at a wall.

If you’re familiar with anonymous functions, then the following code should be clear. If not, though, take a look and I’ll explain what’s happening after the block:

add_action('admin_init', function () {
    echo '<style>
            body {
                background-color: #f3f3f3;
            }
          </style>';
});

Anonymous functions are generally useful when you have a small, one-time callback that doesn’t need to be referenced elsewhere in your code.

Obviously, the functionality is the same, but it raises the question: How do we call remove_action on this function? That’s something we’re working towards, but first, here’s what happens in PHP whenever you’re working with anonymous functions.

PHP Closures, Closure IDs, and Registration in WordPress

Before reading any further, note that a closure in PHP is a way to create an anonymous function.

Just like what’s demonstrated above, it allows us to write a piece of code that can be registered with a hook or, more generally, passed around as a variable. The latter part of this will make sense after we look at what PHP does when an anonymous function is created.

PHP does two things after you register an anonymous function with a WordPress hook:

Generates an ID for the closure. To generate a unique identifier for this closure, WordPress uses the spl_object_hash() function.
Associates the ID with the callback. The generated closure ID is then associated with the callback function, allowing WordPress to track and manage callbacks even when they are anonymous functions.

Given this, another way to write and associate an anonymous function with WordPress would be like this:

$adminInitCallback = function () {
    echo '<style>
            body {
                background-color: #f3f3f3;
            }
          </style>';
};

add_action('admin_init', $adminInitCallback);

And we can get the ID of the closure as generated by PHP by passing the variable to the spl_object_hash function. For example:

$closureId = spl_object_hash($adminInitCallback);

And that will return the ID that’s generated by PHP and associated with the specific hook in WordPress.

But Still, Deregistering Anonymous Functions?

Though this doesn’t help explain how to deregister anonymous functions, it does help explain how things work within PHP.

This will make it easier to explain ideas around anonymous functions ands hooks in a future post.

Meetings Are Inevitable (Quality and Frequency Vary)

January 3, 2024 / Tom

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.

A project manager that not only tracks tasks for software, but works on mathematical proofs in her free time.

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.

Standing meetings are not like this. Especially in a remote company. This looks like a scene from Silicon Valley.

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).

I guess everyone is in the conference room for a meeting that could’ve been avoided if only they’d had a proper project manager and expectations for their meeting.

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.

Writing About WordPress in the Age of AI

January 2, 2024 / Tom

Periodically, I review the content I’ve written over the last decade or so and am surprised to at some of the things I wrote about in the past (like My Day-to-Day). I also find it interesting that I stopped doing so. Then again, I likely exhausted that particular topic. At least for that time.

Specifically, I’m surprised that I used to write about such things despite the topics not really being relevant to what I consider my core content.

Personally, a lot has happened in the last, say, roughly five years alone – between changing jobs, growing the family moving, pursuing additional hobbies, and more – one of the things that’s taken a back seat is writing. Then again, though, isn’t that how it goes?

We have a finite number hours on how to spend our time and as that time gets allocated to other things, something gets squeezed out. And that’s what has happened with writing.

This gentleman fears the amount of time that’s passed. The perpetual ticking that surrounds him isn’t helping.

For a while, I felt guilty about it. Partially because writing daily was something that I enjoyed doing and that I did habitually. Partially because it had become such an habit that when I didn’t do it, I felt as if I was dropping the ball on something.

And though there’s truth in some of that (such as I miss writing every day), that doesn’t mean I’d trade out some of the things I’m doing that occupy that time now. Some of it’s related to my day-to-day work, some of it’s related to my family, and some of it’s related to other hobbies.

Over the holidays (and as I’m trying this, I realize I didn’t write a short Christmas post for this year which is likely the first time since I can remember not doing that), I had time to think about a lot different things some of which included both how I want to spend my time and how I currently spend my time.

Though I’m not one for setting resolutions, I’m for settings goals. And I was planning different goals for myself over the coming year, I couldn’t help but reflect a bit on this site.

Apparently, this is how Meta imagines me doing exactly what I just described. I’m drinking something out of a pepper container.

Sure, the goals would be fun to share (and maybe I will in a future post – I always enjoy what other people are planning!), I found myself thinking a little bit about software development, WordPress, the WordPress economy, where things have been, and where things are headed.

But writing about WordPress in the age of AI especially as developer is proving its own set of challenges. Of all types of people, though, shouldn’t we be here to meet it?

And with the rise of popularity in AI, the more-or-less standardization of the Block Editor, and the upcoming changes to the administration area UI, there’s a lot that can be discussed and there will likely be a lot about which to write (either via commentary or tutorials on how to achieve something).

When thinking through that, though, I found myself remembering all of things about which I used to write that weren’t always dedicated to programming but were still dedicated to what I, as a remote developer working in software developer in WordPress, was doing.

Why did I stop doing that? And what’s to stop me from doing that again?

I used to write differently about things. How did I get here?

Just as I do think tools such as ChatGPT has wrecked some of the content I (and others) have historically written, it’s by no means a call to inaction – or a call to stop writing. It’s just a call to adjust and keep moving forward.

Though I don’t know if I’ll ever write daily again, I do think there’s plenty I can share that extends beyond:

Here’s what you may want to do in WordPress using PHP or JavaScript
Here’s how you can do it.

So at the end of 2024, we’ll see how I’ve done. Here’s to a greater variety of content all the while still keeping the focus on the type of content about which I’ve historically written.

The Most Useful (Or Popular) Articles from 2023

December 20, 2023 / Tom

Last year, I wrote the first type of article that I’ve written in a very long time (if ever) given the amount of time that I’ve been writing. The Most Useful (or Popular) Articles from 2022.

There was generally derived from analytics data but also I used light engagement metrics via X/Twitter, LinkedIn, and even email to determine what were considered the most useful (or popular) posts.

This dude is completely scared of the fact that the calendar is nearing the end of another year.

And given that we’re nearing the end of 2023, I thought I’d do the same this year. So, in keeping with the previous trend, here are the most useful (or popular) articles from 2023.

2023: Most Useful Articles

The Architecture Astronauts of WordPress. Solving the problem is what’s useful. How you solve it is useful, too, but the architecture can be secondary to how it’s solved.
How To Import Programmatically Defined ACF Data. In this post, I’m going to cover how to import a programmatically defined ACF group. And in the next post, I’ll talk about solutions for migrating data into its own table.
How to Run Custom Functionality Once in Multiple Plugins. What’s a way to check to see if a file is already running in the context of another plugin before running it’s code?
Manipulate Incoming WordPress REST API Requests. Note the rest_pre_dispatch hook is triggered before the REST API request is processed by WordPress. This hook allows us to intercept the incoming request and manipulate it in whatever way we need.
How To Build Headless WordPress Applications with a REST API. I have a set of tools that I’ve found and consistently use when building headless WordPress applications with a REST API.
ChatGPT Wrecked Our Type of Content. When you’re someone who enjoys writing about technical concepts for yourself and others, the ultimate goal isn’t to show someone how to quickly do something. More so, it’s to show how to approach problem solving in the abstract and to understand the tradeoffs of various solutions.
The Term ‘WordPress Adjacent’ Should Be More Precise. First because I believe it’s important for us to be able to clearly define about what we’re talking and how it relates to WordPress. And secondly, so that our audience can follow it.
You Rarely Get Greenfield Projects (Or Do You?). If courses teach you’ll be building more greenfield projects than not, I’d be hesitant to consider it a well-rounded education in software development.
Thoughts on the Upcoming WordPress Admin Redesign. There’s likely going to be some friction – as is the case to come with any major updates – but I’m optimistic that we’ve learned a lot from how Gutenberg was initially developed and rolled out and I hope to see others work even more closely with the administration experience to make the transition easier both for developers and users.

For the last few years, I’ve claimed that I want to write more than the year before and get back to how much I was writing in a few years prior. Truth is, I don’t know if this is possible given how much has changed since this. Work is different, life is different, and the way my day-to-day is structured is different.

It’s all great, but it’s different.

Regardless, I still urge everyone with a blog to continue doing the same and then syndicating out to the web. It helps surfacing your content in search engines, on social media – be it X/Twitter, LinkedIn, Facebook, whatever, – and on RSS (which is still my personal favorite).

Father Time wrapping up another blog post for the end of another year.

Anyway, these are the posts for this year. On to 2024.