Software Engineering in WordPress, PHP, and Backend Development

Author: Tom (Page 2 of 424)

Disconnect From Your Job (It’s Not Impossible)

In the penultimate note from What Do You Expect From Being a Software Developer?, Mensur makes the following claim:

It will be almost impossible to disconnect from your job

If you’re someone new to the industry – be it someone who’s up and coming from high school or university or if you’re someone who’s switched careers – comments like this can make it seem daunting.

Note, however, he also states:

So I publicly admit, that I have a hard time disconnecting from work.

This is good because it doesn’t have to be difficult to disconnect from your job. In fact, it shouldn’t be difficult to disconnect from your job.

Continue reading

Is Uncertainty the Toxic Friend in the Relationship of Software Development?

However you’ve come across this article, it’s the eighth in which I am evaluating the claims of another developer’s article –  What Do You Expect From Being a Software Developer? 

From the first part in the series:

At the very least, perhaps these things will be something to keep in mind if you’re looking to enter the industry or even for who have been working in the industry. At most, that article is something that provides a solid perspective from one person’s experience (which likely echo many others, too).

And I’ve been slowly working through each point since. In this post, I’m looking at one that states: Uncertainty will be your toxic friend.


The Relationship of Software Development

Originally, I planned only to go through the list of things provided in the post and comment on them, but the idea of relating “uncertainty” and “toxic friend” piqued my curiosity a bit.

On Toxic Friendships

That dude and his toxic friendship with the computer.

To that end, I decided to dive into the various corners of the Internet to see how “toxic friend” is defined.

  • [A toxic friend] is usually someone who brings elements of dysfunction and unhealthiness into the relationship dynamic or group. Psychology Today.
  • Toxic friendships can take different forms, but they generally drain you mentally and have a way of bringing you down instead of building you up. Healthline.
  • Signs of a Toxic Friendship as outlined by Psych Central.
  • [Toxic friends] often backstab, gossip, lie, act selfish, use, belittle and even manipulate and are taking more than giving back to the friendship. Urban Dictionary.
  • A toxic friend is someone who consistently exhibits harmful behavior, such as manipulation, negativity, or betrayal, causing emotional distress and negatively impacting the well-being of the relationship. ChatGPT (and all of the sources who trained the underlying model).

This isn’t meant to be completely facetious as there is validity in what’s said, but I generally consider “uncertainty as part of the job” and nothing more. But personifying it as a toxic friend? Maybe that makes sense. Maybe not.

Uncertainty in Software Development

The existential threat of uncertainty.

Here’s my experience, point by point.

Third-Party APIs

[Implementing] something in your project you never worked with, eg. 3rd party API – how are you going to implement something you aren’t familiar with?

This is true.

Whenever we’re tasked with having whatever application we’re working on interface with a third-party, there’s almost always a learning curve. (I can’t think of a time where there wasn’t but I can’t speak for everyone so I don’t want to speak in absolutes.)

Sometimes, the learning curve is steeper. It depends on, say,

  • authentication to access the API,
  • the arguments for the API,
  • and how to process what it returns.

Further, if the documentation for the API is wrong then it’s a matter of looking at what’s returned and trying to figure out how best to work with it, or it’s a matter of hoping whoever supports the API is willing to look it, offer guidance, or perhaps even update the endpoints.

Regardless, learning how to integrate with a new API is one thing. Hoping the documentation provides exactly what’s needed or finding a resolution if it doesn’t is another level of complexity for which we ought to plan.

Learning a New Technology

[Transfer] to a new project, with new technologies – you will think about how you are going to be efficient and productive with something you need to learn?

I’d go as far to say that this is something that may still be challenging even working within the same segment of the industry.

For example, if you’re working with one organization and they have certain:

  • coding conventions,
  • branching and merging strategies,
  • continuous deployment set ups,
  • testing methodologies,
  • and so on,

And then you move to another organization that differ, even if it’s just in one area, then it’s something new to learn.

Lay all of that on top of moving from one stack to a completely new stack and you’ve got a handful of new tools, technology, and methodologies with which you need to work.

Again, this isn’t just one level of uncertainty. It’s multifaceted.

Moving To a New Company

[Move] to a new company – you are unsure how you are going to settle in and vibe with new people.

I don’t think this is something that’s deserving of much more commentary than I’ve already offered especially in the previous section.

It’s worth noting, though, that in our field it’s far more likely you’ll be changing jobs than not. This isn’t to say that you can’t – or won’t – stay at a place for a very long time, but the statistic for programmers changing jobs used to be something like every three-to-five years or so (CodeMotion). I’ve also read statistics that it can be as frequently as every two years (Invene).

I’m not arguing for or against this. (Personally, I think each person needs to do what’s best for himself or herself.) But it’s worth noting this will obviously require having to learn new things especially if you’re expecting to move to a new company.

Bug Reports and Deadlines

[Bug] report on the day you need to finish the work – you fear that you are gonna break the deadline

If I was to give a TL;DR to this section, it would be something like this: Yes, I agree. But I also contend that, if given you opportunity, as how project management works at the organization in question. Because they can make or break this particular level of uncertainty.

I have a longer take on this, too.

Yes, this happens from time-to-time but there are safeguards that can – or maybe should? – be placed around any given sprint of work to account for this. And if you have a good project manager, then it shouldn’t be a problem.

For example, let’s say you have a sprint and you and your team have completed all of the necessary work to ship the sprint to QA or whoever will receive the work. But just before you’re tagging the release, a bug report comes in from the prior sprint that affects the work in this sprint.

As frustrating as it can be, it’s also something that should be expected. It’s one of those “hope for the best, plan for the worst” situations.

That is, each time a new sprint has started, there can (read: should) be time built into the new sprint such that it accounts time for bug reports to be introduced so they can be addressed.

No, you can’t anticipate how many nor reports you’ll receive nor can you anticipate how said bugs will be to resolve so there’s always a level of uncertainty in the planning, but if you’re adding time to your sprint to account for this then there should be less stress in missing the deadline because you’ve accounted for the uncertainty.

Then, you’ve got a best case/worst case scenario: Either you’re going to ship everything you planned earlier than expected or you’re going to ship what you’ve planned in addition to fixes.

On certain teams, perhaps you’ll even be able to grab another task from the next sprint and bring it into this sprint. That’s a positive outlook on uncertainty.

On Job Security

[Job Security] – economic situations, pandemics, wars, and other factors heavily affect this industry which results in layoffs

There’s really not much to contribute to this. Few parts of the economy are immune to factors that may negatively impact employment.

I don’t find this unique to working in tech. This, above all other criteria, is something for which we should always plan.

The only commentary I have on this is that if you have the ability to save for three-to-six months of your expenses, then that can sometimes help offset when these things happen.

New Technology (Tools and AI)

[The] evolution of technology – you are never sure if tomorrow you are gonna be replaced by some new technologies like AI

This point is the one I’ve had to consider the most because, for the 15+ years I’ve been working in this field, I’ve never truly been worried about a new piece of technology – be it software or hardware – replacing anything I or any of my colleagues jobs.

NEW TOOLS

If anything, as new tools have come – and some have gone – they were things that we were expected to learn and sometimes incorporate into our day-to-day work. They weren’t advanced enough to replace anything we were doing. They accelerated what we were doing, sure, but only after successfully learning said tool.

And even though we’re in a surge of tools being built with AI, it’s still not something about which I’m worried taking my job. If anything, it’s helping me get more work done quicker and it’s helping us to build tools that enhance our software if anything else.

AI

That said, I can only really speak as to how AI is affecting or impacting my job as a software engineer. I can’t speak to how it may affect someone in this industry that’s engineering-adjacent but I still don’t yet see how it’s going to truly replace a given job.

Even the tools that promise to help plan schedules based on, say, the backlog of tasks and the availability in each person’s calendar, it also makes the assumption that the data it’s being handed is up tot date and we’re assuming it can correctly estimate based on the data it’s given.

AI’s impressive, to be sure, but there’s a lot of assumptions happening based on the solutions it provides and those assumptions can cost a lot of money without the proper safeguards in place.

If anything, AI is enhancing the way we get things done and it’s allowing us to build tools that we couldn’t do so two years ago. But there still has to be someone able to interface the software being built with the AI to which its communicating. And there has to be someone to make sure the models are returning data that’s relevant to what’s being asked.

There’s still much to be explored within the field of AI and it’s something I think all technologists should be following. This isn’t because we should be looking over our shoulder for what’s coming for us, but look at how we can use this to help us in our day-to-day.


Certainly Uncertain

I’m not certain this is how we should be doing our jobs.

Though I largely agree with all of this, the biggest difference I have is treating uncertainty in and of itself as anything different than something that comes with this job. I don’t think the original article was disputing this fact. If anything, it explains what to expect so you’re not surprised.

But if I’m sticking with the analogy, is uncertainty something that “brings elements of dysfunction and unhealthiness into the relationship?” I don’t know if I’d go that far. Learning something new, how to interface with a third-party service, or working with some other technology isn’t necessarily dysfunctional nor is it unhealthy.

It can be exhausting, it can be challenging, it can be frustrating, it can be exciting, but it can be expected.

So as much as I agree with the article and as much as I think uncertainty is something we all should expect, I generically don’t consider it toxic.

How To Configure Laravel Herd, Xdebug, and Visual Studio Code

I’ve recently switched to Laravel Herd for local development. It uses Valet internally, which I obviously like, and comes with a lot of tools out of the box that make some of the overhead of development much easier.

It’s a hard hard at work.

And any utility that makes it easy to focus on actually writing code while reducing anything that deals with reading logs, configuring different versions of PHP, and even debugging is something I’m in favor of using.

Off the shelf, Herd makes debugging with PHPStorm easy; however, if you’re to get started with Laravel Herd, Xdebug, and Visual Studio Code then there’s a little more configuration to do.


Laravel Herd, Xdebug, and Visual Studio Code

A Word About Herd Documentation

I want to point out I think Herd’s documentation and file structure is one of the best I’ve seen. It’s easy to understand, easy to navigate, and easy to find various configuration files – say php.ini or debug.ini – regardless of the version of PHP you’re using.

A quick example of the directory structure of how Herd organizes its files and configuration.

Case in point, see the following pages:

That said, there’s not much in the way of how to configure Xdebug and Visual Studio code.

Herd, Xdebug, and Code

Here are the steps what worked for me to get my local environment setup. Note this was tested with PHP 7.4, 8.0, and 8.2.

For the following example, note I’m using Apple Silicon and am going to be using PHP 7.4. Very few things should be different save for the paths to the files references in the below code.

HERD

Changing PHP versions is trivial in Herd. This is a matter of selecting the version you want to install and/or marking it as active for your current site.

I mention this though, because it’s important to know which one you’ve got activated so you can properly update the relative Xdebug configuration.

XDEBUG

Unless you’ve set up Herd in some abnormal manner, you should find the extension in the following path:

/Applications/Herd.app/Contents/Resources/xdebug/xdebug-74-arm64.so

From here, you want to open the relative php.ini file and add the following. Note that this is different than what the Herd docs show. I don’t know if it’s because they are specific to PHPStorm or not, but this is what worked for me with Visual Studio Code.

First, locate the php.ini file in the following path:

/Library/Application Support/Herd/config/php/74/

Then append the following to the file:

zend_extension=/Applications/Herd.app/Contents/Resources/xdebug/xdebug-74-arm64.so
xdebug.mode=debug,develop
xdebug.start_with_request=yes
xdebug.start_upon_error=yes
xdebug.idekey=ECLIPSE
xdebug.client_port=9003

You should not need to touch the debug.ini related to the the PHP version in the same direction.

VISUAL STUDIO CODE

Finally, in Visual Studio Code, create a .vscode directory if it doesn’t already exist in the root of the project. Next, add launch.json to the directory.

In that file, add the following configuration:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for Xdebug",
            "type": "php",
            "request": "launch",
            "port": 9003
        },
        {
            "name": "Launch Built-in web server",
            "type": "php",
            "request": "launch",
            "runtimeArgs": [
                "-dxdebug.mode=debug",
                "-dxdebug.start_with_request=yes",
                "-S",
                "localhost:0"
            ],
            "program": "",
            "cwd": "${workspaceRoot}",
            "port": 9003,
            "serverReadyAction": {
                "pattern": "Development Server \\(http://localhost:([0-9]+)\\) started",
                "uriFormat": "http://localhost:%s",
                "action": "openExternally"
            }
        }
    ]
}

You’ll likely need to restart Herd after this so issue the $ herd restart command in your terminal.

Conclusion

Now you should be able to set breakpoints, add watches, step into code, and all of the usual things you can do with the Xdebug but in a Herd environment.

And if you’re completely new to Xdebug, I wrote an extensive tutorial on it some time ago.

Working in Software Is Better Than Hardware (Bugs Are Part of the Job)

The dictionary defines archenemy as “the chief enemy” where enemy is defined as:

noun,plural
en·e·mies.

  1. a person who feels hatred for, fosters harmful designs against, or engages in antagonistic activities against another; an adversary or opponent.
  2. an armed foe; an opposing military force:
    The army attacked the enemy at dawn.

And I mention this because the original states that “bugs will be your arch-enemy for life.

The arch-enemy of many a software developer.

Obviously, this is hyperbole but if your primary job as a programmer is to ship functioning code and bugs prevent said code from working or it results the program yielding unexpected behaviors then, yes, you will forever be fighting them.


Bugs Are Part of the Job

Before writing this article, I thought about the various different projects I’ve worked on during my career and how bugs have affected each of them (including ones I’ve introduced).

  • Some of these projects include enterprise grade web applications with various data center used throughout the United States.
  • Others are small utilities that have maybe a dozen users.
  • And then there’s a variety of everything in between.

There’s no succinct way to talk about how bugs are introduced, grow, change, are squashed, and are reintroduced into a software system.

Just another day in the life. Write code and deal with bugs.

The original article has a pretty good statement:

So the truth is you should assume that everything has bugs. That’s why experienced devs never trust their code if it runs successfully on the first try. Even if the QA engineer reports a bug, assume that the bug ticket has a “bug” and check for everything.

And I really like the idea that “you should assume that everything has bugs.” That’s the bottom line, full stop.

I Choose Software Over Hardware Any Day

Software is a broad term to encompass all types of products we use:

  • iOS apps
  • Android Apps
  • TV apps (regardless of the vendor)
  • Web apps
  • Extensions
  • Plugins
  • Utilities
  • Operating systems
  • Components
  • And on and on it goes.

It’s amazing human beings can collaborate to produce such things (regardless of the environment) and that these things continue to work despite the high potential and likelihood for error that exists.

He’s astounded as much as I am that any of this works.

Sure, we can put in place all types of automated testing around the code, we can hire QA engineers to test all sorts of edge cases, and we can have entire support departments dedicated to handling user feedback, requests, bug reports, and so on.

And still they persist.


Rather see them as an enemy that has to be defeated, overcome, or reduced into nothing as if there are two sides two a war, I prefer to see them as just as part of the job.

Yes, they are frustrated, yes fixing one can lead to another, and yes sometimes an improper merge can end up bringing a previously squashed bug back into the codebase.

But it happens.


For what it’s worth, one of the things that I’ve told myself over the years is that I’d much rather be working on software rather than hardware because the former affords us, among many other things, the ability to ship fixes, patches, and updates in a far easier manner than a physical product.

Software Developers and Technical Articles in the Era of AI

Site analytics are funny things regardless of how you use them (that is, through marketing, engagement, content, and so on). I say this because analytics give us information about:

  • how long people are reading our content (per article, even),
  • how many people are reading what we write,
  • how much people are reading what we write,
  • how often people are returning to read what we write,

And all of this coalesces into informing the things about which we write and how we write about it. At least, this is my experience.

The day to day experience of understanding analytics through the use of two mice.

Despite having all of this analytical information available, AI is changing the type of content we publish.

For technical writers specifically, this should give us pause on if there’s not a slightly wider range of related topics about which we can write that continue to contribute to the field in which we work.


Technical Articles in the Era of AI

As far as analytics, SEO, AI, and all of the other related technologies to blogging are concerned, I still hold to the mantra I’ve had for over a decade:

Write what you want on a given topic and don’t over think it.

This has proven the most useful and has transcended whatever changes have happened within the industry.

I primarily write because I enjoy the process, but it’s afforded opportunities that wouldn’t otherwise be available (the least of which isn’t developing solid friendships with people I’ve met in conferences or online).

Even still, I – like anyone else who’s maintained a site for a reasonable amount of time – still pay attention to some level of information analytics provide.

On Analytics

I rarely do a legitimate deep dive on the analytics of my site. Generally, I like to see:

  • the number of visitors over time,
  • how much time they are spending on the site or on each article,
  • and the bounce rate.

I’ve developed this habit in part because I’ve been writing technical content for so long it’s of some interest to see if people are [still] paying attention to it. But, as the advent of AI (see this post) has hit the mainstream of this industry, there’s been a change in how we all look up technical content.

And where analytics may have been useful for a very long time, there’s now another dimension to the field.

On AI

Given blogs and technical articles have helped train the LLMs we’ve so quickly adopted, it raises questions.

Is it useful to continue writing technical articles?

  • If the content we wrote helped train the LLMs then are new articles also continue to add to the data set the LLMs are using?
  • If more and more developers – myself included – are going to an LLM to help solve problems first (versus a search engine), how much less valuable are other sites and blogs becoming?

I still think there is value in treating a blog like a public notebook of sorts even if it’s just for personal reasons.

If not, then what else is there for technical writers to publish?

  • I don’t think there’s any shortage of content engineers have to write because so much of our job is more than just development, architecture, and so on.
  • The amount of things tangentially related or even adjacent to our work provide plenty of content that’s useful for other people to read (take articles like this and or this, for example).
  • As the technical aspect of our jobs may be enhanced – or substitute whatever word you’d like – by AI, there is still a human factor.

Clearly stated: As long as a human experience exists as something unique, it has potential to be an article that cannot be wholly generated through the statistical probability of words assembled through generative AI. (Though I’d be foolish to say that it can be a challenge to discern the difference between what a person has written and what has been generated.)

Writing technical articles does not have to be published into the void.

Though it may be easier to refer to ChatGPT for a technical question rather than a blog, that doesn’t mean a developer has nothing about which to write in relation to the field. For example, just as I could write about my day-to-day in working from home as a father of three an trying to maintain a schedule for reading, writing, exercising, music, work, and continued growth in what I do for a living, so can any one else. (Or so should everyone else?)

Software Developers Should Expand Topics

Ultimately, the way our work is altered through the advent of AI is undeniable. And though it may mean there are some changes in how we get our work done, it also informs how we can continue to contribute content related to what we do in our day-to-day. (This is something I used to do way back when, too.)

In other words, looking up how to properly sanitize data before it enters a database is going to be something the current – and the next – generation will ask an LLM. But looking up how to be productive as a remote engineer living in rural Georgia in a family of five, three of which are kids, is something AI cannot answer.

And perhaps that’s an area in which we could easily – and should – expand our content

« Older posts Newer posts »

© 2024 Tom McFarlin

Theme by Anders NorenUp ↑