Software Engineering in WordPress, PHP, and Backend Development

Tag: Software Development (Page 3 of 20)

You Rarely Get Greenfield Projects (Or Do You?)

TL;DR: I’ve found this to be true in my career. In my experience, whether or not you get a greenfield project depends on your company or the nature of your team.

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.


Greenfield Projects Defined

For the purposes of this article, I’m using the definition of greenfield project from Wikipedia:

In many disciplines, a greenfield project is one that lacks constraints imposed by prior work. The analogy is to that of construction on greenfield land where there is no need to work within the constraints of existing buildings or infrastructure.

By definition alone, it seems near impossible to think about starting a true greenfield project. I mean, if you’re building something from scratch you have the ability to pick every set of technology and standards the team will used to build the project.

But most projects start with some type of foundation these days. With some extreme exceptions, most things are going to start at the operating system level or will use a platform like the web and likely some type of framework that sits on top of it.

And to that end, there are already certain things in place that constrain what we can use.

The Greenfield Litmus Test

If anything, I’d say a greenfield projects depends on what you consider truly starting a project from scratch.

  • Absolute purists might claim that a true greenfield project is nothing but bare metal. No operating systems, no available programming languages, etc. Everything starts here and moves up.
  • Others may draw the line at an existing operating system, existing platform, existing framework, or something like that.

When it comes to greenfield projects, I’m of the mindset that once you know what platform on which you’re building, then you determine if a project is greenfield or not.

Perhaps this is a litmus test:

  • If you’re building software that’s going to operate on or within the context of a pre-existing product, then it’s not a greenfield project.
  • If you’re building something completely new to bring to market, then it’s a greenfield project.

It’s easy to start splitting hairs so I’m not going to keep going but this is the filter through which it may be helpful to think of such projects.

Very Few Greenfield Projects

In my career, nearly everything I’ve worked on has either been a feature for a larger project (and yes, some features can be so big they take entire teams – especially at the enterprise level) or has been maintenance on a pre-existing project.

There are a few years were I worked with a very small team and we were creating several products from scratch. And the reason we were able to do that was because we had started a business of our own and were building and selling the products.

But even after those products had become more established, then we swapped into the phase of maintaining and improving the projects. So if a greenfield project comes your way, it doesn’t always stay that way.

As for now, there’s a lot of work I do that’s either related to internal tooling or based in research and development. There are times where a project may be seem like it’d be greenfield but the requirements usually dictate what’s necessary to start the project. So even then, there are constraints in place.

Do Colleges Teach You Often Get Greenfield Projects?

I don’t know what most colleges, universities, or other courses teach. This statement piqued my curiosity because I think that a lot of projects that teach software development concepts are initially done so in a vacuum. But after a certain point, you’re working with something that already exists – even if it’s small.

Though just about everything I’ve worked on out of school has been on a pre-existing project, there were also plenty of projects I had in school that were focused on adding things to projects that already existed.

Sure, some of the projects were in place so we had to learn how to work with existing codebases, but others – especially during internships – were all about maintaining existing software.

Ultimately, you’re likely to have a mixed experience but I’d venture to say the majority of projects are not greenfield.

If universities or other forms of education aren’t providing you with opportunities to learn how to both build a project from scratch and to maintain existing projects, then I’d be hesitant to consider it a well-rounded education in software development.

Colleges Don’t Teach Useful Software Development (Do They?)

With regard to what I shared in the previous post – What Do You Expect From Being a Software Developer? – the author provided 10 things I enjoyed and thought it’d be a good exercise to look at each point through my own experience.

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

This lead me to think about my experience both in college and in my career in software development and how it relates to the ten points mentioned in the last post. It’s easy to say colleges don’t teach useful software development, but how true is that? Again, I’m not arguing the original post. But perhaps my perspective is a different.

I’m not going to give a deep dive into my entire history doing this (who would want to read that, anyway? :) but why not share my on the 10 points mentioned?


Distinguishing Between Computer Science and Software Development

I think of computer science and software development as two different things.

This is an important distinction because if you’re talking to someone who works in the field of computer science, they may or may not be in the field of software development; however, if you talk to someone in the field of software development then it’s likely they’ll be doing exactly what the title implies.

And as the field has grown in the last 10-15 years, entire degree programs or certification programs specifically for software development have emerged (as opposed to those just for computer science). That said, there are also degrees and certifications that have a foundation in computer science with a focus in software engineering, software development, web development, and so on.

All of this is worth mentioning because when we start talking about the case of if college will prepare you for a career in software development, I think it’s important to be nuanced enough to map what the college program was teaching versus what you’re expecting from the job market.

Further, it’s also worth stating that it’s not required or necessary to go to college to get a job in this job market. This was the path I chose; others have their own.

“College Will Not Prepare You for the Job”

This is where I think it’s important to distinguish between computer science and software development. When I was in school, I majored in computer science with a focus in software engineering.

If I had to summarize it, I took a lot of classes that were focused on computer science – that is, a lot of math – and then I had a lot of courses on software engineering – that is, how to analyze, design, build, and/or maintain software. For experience, I worked as a teaching assistant and participated in a few internships.

So there’s my context for the experience I’ve had thus far.

In the original article, Mensur writes:

The college will prepare you for some basics, but what most of the colleges teach is so far away from day-to-day jobs. Most of the professors who teach at universities are not good software engineers.

Only a small percentage of them even worked as software engineers. Also, the university curriculums are heavily outdated. They trot years behind the software development market needs.

college will not prepare you for the job

There are three main points in this passage I found most relevant to what I’ve done over the last 16 years (including what I’m doing now).

1. Most Professors Are Not Good Software Engineers

I can definitively say in my experience, you could tell who were the academics and who were the practitioners.

This isn’t to say either is better than the other. If, however, you’re going into the job market then those who have been there have something to offer than those who have been in academia. Conversely, if you’re looking to continue on the track of research and education, then those who have worked in the job market may not be the ones who are your best resource.

Even then, you have to know if the professor is working at the university for research or they are practicing software development by building out something that’s yet to be made publicly available. Some institutions do that and, as such, it’s not as easy to cleanly divide the two.

Generic class room all too similar. Photo Credit.

First, I can unequivocally say the professors who had the greatest impact on my career and my interest in software as a career were those who had spent time outside of an academic setting and worked in the industry (in fact, I still remember their names and many of the projects we did for those classes because they were designing from real world scenarios). A lot of practical skills were taught.

Secondly, I’m not saying those who had not worked in the industry weren’t good professors. Their methods of teaching and the projects they assigned felt far more academic in nature. A lot of theory was taught.

I know: Giving two examples relevant to my own experience doesn’t make or a solid case in one direction or the other. The goal is just to add another perspective to another published article.

The point is simply this:

  • The majority of the professors who prepared us for working in the industry were those who had already been there.
  • Those who had not worked in the industry were teaching foundational concepts – they were teaching us how to think.

And I’ll have more to say about that later.

2. University Curriculum Is Heavily Outdated

This point isn’t going to be very long because I can’t speak to the state of university curriculum. Generally, it’s a strong maybe from me. I’m sure it depends on the university or the program in which you’re enrolled.

At the time, I didn’t feel like much of the content I was learning was out of date. But it’s hard to know when you’re in school, right? What do you have to judge it against?

But looking back, there’s only one course that I took that felt out of date for me and it didn’t so much have to do with the content but it had to do with the language we were using: Smalltalk.

There’s a caveat here, though: Part of the reason we were tasked with using Smalltalk was because it was also to help inculcate the foundations of object-oriented programming where everything is an object that receives messages (versus classes and functions that are invoked on an instance of the class).

So even that served its purpose because it told us how to conceptually adapt to a weird requirement.

And for those who are wondering, there were a lot of languages used in school at the time (Java, C, Python, Smalltalk, JavaScript, SQL, and so on). But to say this is heavily outdated isn’t as true as it might be for others.

  • Was Smalltalk outdated? Yes. But I recognize the concepts taught in that class along with designing or improving object-oriented based systems were the most useful.
  • What about working with a team to scope, design, build, and test a photo sharing application? This was more applicable to what I was going to be doing day-to-day.

Now, I’ve probably forgotten certain things we were taught that are no longer needed – as is apt to happen – but one thing I distinctly remember learning that I only used in my first job out of school were UML diagrams.

I get the point of them, I understand what they are supposed to convey, but rarely do teams have the time to do this when tasked with a project. Further, it’s harder to diagram part of a project when a much larger system already exists (especially if even part of it is a legacy system).

3. Learn How to Learn

As I mentioned in the first point, the biggest advantage that I came away with when graduating with my degree was that I had learned how to learn.

No, I didn’t know all the languages but I didn’t need to know them. No, I didn’t know all the various tools, systems, languages, platforms, and so on, but I knew how to learn and adapt. And that one skill alone has likely been the one that’s paid the most dividends.

So if you’re in a program – be it something from freeCodeCamp, a course in high school, at a local college, a university program, or anything in between – it’s important to learn how to pick up something new and integrate it into your workflow.

For example, when you understand how something, say dependency injection, works in one language, it’s more or less matter of semantics when using it in another language. And that’s because the act of being able to do a thing transcends the tools used to do the thing.

Anyway, figuring out how to learn is key and we all have different ways of doing it so it’s important to find what works best for you. If that means going to office hours, doing independent reading, watching more content on YouTube, or meeting with the professor or a group of other students, or hanging out with like minded people at a conference, then do it. Whatever opportunities available that are tailored to sharpen your ability to learn, take advantage of them.

Ultimately, learning the why behind something helps you start formulating your own ways of how to learn something new. And when you get a good hold on that, picking up new technologies or applying something from a previous project or a previous job into a solving a new problem becomes easier.


Nothing I’ve shared here is a rebuttal to the previous article nor is it meant to even be argumentative. If anything, this is additional content. It’s an extension to an article someone else has already written.

And if anything else, this is a good exercise in writing something other than how to achieve something programmatically.

What Do You Expect From Being a Software Developer?

Not everyone who works in software development has a degree in computer science (or a degree at all), and I’m not suggesting that you should.

However, if you have ever taken a class, course, or degree program in computer science, software development, or programming in general, there were likely certain assignments or projects given to illustrate specific concepts.

For some, there were even capstone projects that required working on real-world applications. These types of projects, along with internships, are often the most valuable, as they allow you to experience what it’s like to work as a developer or engineer in a professional setting.

In other words, I don’t know what you expect from being a software developer, but engaging in these types of projects or internships can significantly help you understand the difference between theory and practice, as they say.


To that end, here’s a great article by @mensur-durakovic called 10 hard-to-swallow truths they won’t tell you about software engineer job.

Last weekend I had a chance to talk with some students who just got their degree. They are pursuing their first software engineer job. In conversation with them, I learned that they have a pretty wrong perception of this job. This is because the reality for these new kids is so skewed.

Here are the top 10 things as provided by Mensur:

  1. College will not prepare you for the job
  2. You will rarely get greenfield projects
  3. Nobody gives a f*** about your clean code
  4. You will sometimes work with incompetent people
  5. Get used to being in meetings for hours
  6. They will ask you for estimates a lot of times
  7. Bugs will be your arch-enemy for life
  8. Uncertainty will be your toxic friend
  9. It will be almost impossible to disconnect from your job
  10. You will profit more from good soft skills than from good technical skills

The entire article is worth a read especially because of the elaborations on each of the above points.

I, nor do I think the author, is claiming all software development jobs are like this but many are. I’d venture to say that many software development jobs include at least a handful of these things (and I do feel bad for those who have a job that exhibit all 10 of these).


If you’re ever wondering what it’s like to worth in software development, or you’re wondering about your own ability in your organization, or you’re wondering about your organization in general, maybe read this list.

And maybe I’ll work a few articles with my experience on each of these points. It’d be likely be 10 short reads, but it’d be something. And it’d be something that’d be relevant to many of you who found yourself as an engineer who made their way into WordPress.

Why We Don’t Always Need Do Perform an Early Return

There are a lot of opinions on how return statements should work.

  • Some say that there should be a single point of return in a function,
  • Some day we should return as early as possible,
  • Some day multiple return statements are fine,
  • And some say that, when applicable, return as early as possible.

I’m sure I’m missing some, but all of these are ones I’m sure the majority of you have seen. And though I don’t hold either of these to be law, I think there’s a time and a place for each.


I’m a fan of the early return statement. In my mind, the sooner we can determine we don’t need to do the work of a function, the better we just leave.

For example, say we know if we’re not on a certain page, we can go ahead and leave the function:

In this case, it makes sense because:

  1. You only want to perform work on the plugins.php page,
  2. The amount of work to be done in the function is larger than what should ever fit within a conditional.

But there’s an alternative when the amount of work is less than what’s above.

Continue reading

ChatGPT Wrecked Our Type of Content

A few days ago, Carl and I were talking about the impact that ChatGPT and related technologies have had on those of who spend – or spent – a lot of time writing long form articles showing how to achieve things within the context of software development.

Both he and I, among others – perhaps including some of you who are reading this post or regularly read this blog – have been around long enough to remember what it was like growing up online, learning how the machine works, how to write code, and perhaps even studying it in both high school and college, and maybe beyond that.


The 90s

For me, it was a combination of AOL, the the programming forums, VB3, and then onward and upward to other languages, operating systems, and platforms from there. True story: The first copy of Linux I ever received was Slackware that someone I met in IRC sent to me via USPS. The site doesn’t look enough different today.

So many afternoons, nights, and evenings were spent hopping between playing games like King’s Quest (Six is the best and I’ll fight you for it) and then signing online to see what certain people were building (such as a TCP/IP checkers game built fully in Visual Basic) to random proggies people were using to manipulate AOL, and from trying to wrap my head around C++, to trying to make sense of Dan Appleman’s Programmer’s Guide to the Win32 API.


The 00s

Fast far forward to the early two thousands and sites like Stack Overflow come online (from the minds of long-time bloggers Joel Spolsky and Jeff Atwood, no less) and begin having perhaps the largest scale and gamified way to get your programming-related questions answered quickly.

In fact, I remember listening to the podcast on my iPod Shuffle while running through the suburbs of the north Atlanta metro area. They’d talk about how they were discussing certain aspects of the site from an object-oriented programming standpoint, the technology stack they were using – which was .NET – and they were using Subversion as their version control system.

And I’m old enough to be one of the double-digit user accounts. And I remember them growing into what was originally called The Stack Overflow Trilogy. It was a really cool time to be a young software developer working in web application development.


Today

All of this is to say:

I don’t recall a single new set of sites and/or technologies being introduced that so quickly impacted what those of us who do what we do for a living.

On Blogging

Sure, certain technologies or libraries or languages or tools have come and gone, but when I think about major inflection points of utilities that have impacted software developers, Stack Overflow and ChatGPT (along with its related technologies such as Copilot) are the first thing to come to mind.

I’m shooting from the hip as I’m drafting this late at night and should be giving this more thought, but I digress.

Anyway, during the conversation with Carl, he made the following claim:

I think ChatGPT wrecked our type of content

I’ve been rolling it over in my mind for the past few days not so much because I disagree – I actually firmly agree – but I’ve been thinking about the following two points:

  1. It’s paradoxical. Bloggers wrote the content that helped train a massive LLM that ultimately negate the need for that kind of content. Granted, we could continue to feed the machine, so to speak, but LLMs can learn from themselves given the right interaction.
  2. The goal was never to provide a quick way to copy and paste a solution, but how to learn how to solve a problem when you weren’t sure how to approach it. (And this is something that I think serves anyone in the field of applied computer science well.)

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.

On Social Media

Then I got to thinking about all of the people in WordPress I’ve met over the years, then I got to thinking about all of the people in adjacent groups I’ve met over the years. Those work work in:

  • backend languages,
  • front-end languages,
  • content creators,
  • podcasters,
  • and so on.

So I decided to hop back on to X/Twitter for a bit to see how those people have been using the platform since ownership changed hands earlier this year.

And what I found during my, what you may call, straw poll was that there’s a lot of people who haven’t abandoned the platform at all. Instead, they subscribe for access to the premium features of the platform, who are writing long form content, who are sharing longer form content than I think we’d more likely see on some blogs just five years ago.

So then I brought all of this back to what I’ve traditionally written about and in the field in which I work, and I’ve noticed that there are a lot of people spending a lot of time writing about development work as it relates to WordPress on X/Twitter rather than on their blog.

And here’s why that strikes me as strange:

Old school tweeting was one thing because it included short statements that felt more like parts of a conversation. A very loud, boisterous, crowded conversation, but a conversation of sorts nonetheless.

Now, though, people are writing essays on their premium accounts about content related to a platform that targets the democratization of publishing. An essay does not a conversation make.

Further, publishing content on a platform about the software on which you work that aims to give people the goal to publish content so they can maintain it seems incongruent.

I don’t think anyone should have to make this claim but I’m not someone who cares one way or the other who owns X/Twitter or what’s going on with it from a socio-political-or-economic perspective. The observations I’m making wouldn’t matter who owns it.

Bringing It All Together

So how do I bring the various and seemingly disparate thoughts on all of this together to try to make a cohesive article? I’ll do what I can.

  • Writing about software development and trying to provide quick solutions to common problems are not the same thing.
  • Writing long form articles about the concepts in software development and looking for an answer from ChatGPT or related services are not related.

So the first question seems to come to something like:

  • When people are given the choice to choose between the two, will they search the archives aggregated via RSS first or go to ChatGPT first?

Though the goals of this question are not mutually exclusive, I think getting an answer fast often outweighs the “I’m looking for an answer but it was neat to also read about someone else’s situation while searching for it.” And this is why ChatGPT has “wrecked” some of the content a bunch of us typically write.

It’s not because we don’t want to write it (and no one is stopping us), but it’s hard to know just how many people come for the content and stay for the answer versus come for the answer and stay for the content.

The answer, then, seems to lie somewhere in between either continuing to write as usual, which is a completely viable option, or do what content creator types do and bring the content to the table in a way that’s compelling enough to keep people coming back (or turning in, or watching, or smashing that subscribe button and remembering to hit the bell).

The second observation, though, is a bit less clear to me. Before X/Twitter changed hands, people were already involved in a number of different areas online such as Slack channels for Post Status or The WP Minute, Facebook groups, but they also tended to maintain their own site while sharing their shorter content on X/Twitter (for reasons that I’ve already covered).

Now, the whole thing is all over the place:

  • Some are spending a lot of time writing long form content on X/Twitter,
  • Some are participating in various Slack channels,
  • Some are participating in various Facebook Groups,
  • Some are blogging,
  • Some have pulled back from the social web,
  • Some are doing none, multiple, or all, of the above.

Having choice is fine and picking where to hang out is great – it’s the whole go where you feel most welcome kind of thing – but the degree and/or ways in which many of us have changed in 2023 alone is really something to observe.

Where We’re Headed Isn’t Clear

And, as I said at the outset, the solution to this isn’t clear. If I had to summarize my take it would be something like this:

Long form posts for those on X/Twitter has increased this year and the amount of content people are sharing on their own blogs and syndicating it to X/Twitter has decreased.

I have to leave it at that for now because I don’t know what to make it of it. Maybe it’s just the way it is.

Anyway, Carl also made the comment in our conversation:

I think there’s still space for teaching and writing about concepts

And I agree with this, too. The thing is, I don’t think the way we’ve historically done is it the way to do it moving forward. I won’t be the guy who’s writing his thoughts on X/Twitter (not as a protest or anything) because I don’t see the medium has particularly useful for that in the long term.

I still think blogging and ultimately publishing content on your own property and syndicating it out to social networks is ultimately better than inverting how it’s done (though that’s what’s happening right now).

People can read the content and then take the social aspect of to social media. Or they can drop an email in our inbox. Or they can consume it and move on.

Regardless, how the content is produced is presented is likely the next challenge for those of us who have historically done long form technical writing. And I don’t know what that looks like right now.

Exciting times ahead.

« Older posts Newer posts »

© 2024 Tom McFarlin

Theme by Anders NorenUp ↑