Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Frederick Vanbrabant:
The Broken Windows Theory or "Why Some Projects are Just Destined to Suck"
Jun 20, 2017 @ 09:15:40

Frederick Vanbrabant has posted an interesting article to his site covering the "broken windows" theory, what it is and how it shows that some projects are just destined to suck.

Why is it that most legacy software projects are not really fun to work on? How can we stop that greenfield project to turn into one of those dull big projects? I would argue that it’s all in the foundation.

He starts with a brief description of the "broken windows" theory based on the 1982 definition proposed by James Q. Wilson and George L. Kellin. Basically it states that all it takes is one "broken window" to change the perceived value of something, even if it's a small thing. He then gets down to the code level and relates it back to some examples from the Slim framework project. In his examples he shows how it might look after a refactor and how removing best practices makes it harder to understand (breaking windows). To help prevent it, he recommends following the Boy Scout rule of leaving the code better than you found it and using automation to help find and fix the issues.

tagged: brokenwindows theory software development perceived value opinion

Link: http://frederickvanbrabant.com/2017/06/12/broken-windows-theory.html

Marco Pivetta:
Eliminating Visual Debt
Jun 05, 2017 @ 16:53:12

In a new post to his site Marco Pivetta talks about "visual debt" in your code. "Visual debt" is described in this video as the difficulty in understanding caused by complicated code.

Today we're talking about Visual debt in our code.

As an introduction, I suggest to watch this short tutorial about visual debt by @jeffrey_way. The concept is simple: let's take the example from Laracasts and re-visit the steps taken to remove visual debt.

The code example the post starts with, while a working piece of code, leans towards being more complex than necessary to complete the task. Marco spends the rest of the post walking you through the simplification of this code. He shows how to remove pieces that aren't as necessary, refactor it to remove the enforcement of contracts and some further things you can do to simplify the code.

He ends the post by saying that his suggestions are all sarcasm on his part and shouldn't be followed. By removing things like return type hinting and functionality that enforces good behavior you risk odd issues and poor usage down the line.

tagged: visual debt elimination sarcasm opinion

Link: https://ocramius.github.io/blog/eliminating-visual-debt/

Testing Keeps Me From Getting Things Done
May 25, 2017 @ 09:52:29

On thePHP.cc site they have a new post that tries to refute a common claim from developers when it comes to testing: testing keeps me from getting things done. The post is a response to an email to the group about testing asking where the real value is in applications versus libraries/tools.

To successfully develop software means to work target-oriented. These targets should be derived from acceptance criteria that are reconciled with the business. Without clear targets – we mean at a task level, not project or annual targets – the developer runs the risk of getting lost in work. Most importantly, he does not know when he is done with a task.

It is prudent to document and verify acceptance criteria through automated tests. One way or another, the targets have to be defined before production code gets written. This is test-driven development, whether you want to call it that or not.

The response goes on to talk about how, with tests written after the code has already been written (legacy code), it's not always clear what the original intent was resulting in lost context. It also compares two of the main types of testing - integration and unit - and the place each has in an overall testing strategy.

tagged: testing unittest reply integration opinion application

Link: https://thephp.cc/news/2017/05/testing-keeps-me-from-getting-things-done

Eight Rules for Effective Software Production
May 18, 2017 @ 12:33:27

On the Toptal.com site there's a new post from author Timofey Nevolin sharing hist list of Eight Rules for Effective Software Production to follow to help keep your development process flowing well based on some of his own experience.

During the course of my career, I’ve participated in multiple real life software projects and observed how things are done on all levels: decision making, practices adoption, team building, recruiting, skill distribution, etc. Obviously, different approaches yielded different results. Being an improvement-oriented type of person, I noticed and collected the most effective practices and best practical tricks to help me up in my work.

Learning from observation is a hard and lengthy way to do it. I would be extremely happy to pick this knowledge earlier from books instead. Unfortunately, I found none on the topic. So I decided to share my experience with other seekers of this kind of knowledge. Hopefully, it’ll save them few years of personal research.

His list of eight, targeted mainly at those needing a productivity boost, includes rules such as:

  • Understand the IT Mentality
  • Stop Wasting Time on Formal Time Estimation
  • Understand the Cost of Switching Tasks and Juggling Priorities
  • Use Architecture Reviews as a Way to Improve System Design

He finishes with one of the more important rules to follow: valuing those on the team and respecting them for what they bring to the table.

tagged: effective software production rules opinion development

Link: https://www.toptal.com/it/eight-rules-for-software-production

Being a Good Writer is an Important Career Skill – Learn how to get better at it.
May 18, 2017 @ 09:55:49

On the DotDev.co site Sharon Steed has written up a post suggesting the importance of a non-technical skill that can help you in your career: being a better writer.

No skill will serve you better in your career than being a confident communicator. As important as being able to talk to people is, however, today I want to focus on written communication. Writing often gets a bad wrap, but it doesn’t have to be the dreaded task many of us make it out to be.

She talks about some of her own experience with writing and how it related to the eventual move to public speaking. She talks about how most people she talked to saw writing as a chore and always had their reasons why. She points out that, while most people seemed to dislike writing, they do it all day - emails, chat, texts, etc. She makes some suggestions you can follow to help take the dread away from writing and instill the confidence you need to make it more effortless.

tagged: writer career skill opinion chore confidence

Link: https://dotdev.co/good-writer/

Developers, It’s not all about the code
May 10, 2017 @ 12:45:43

On the DotDev site there's an article from Sharon Steed with a reminder to the developers out there - it's not all about the code (despite what it may seem like in the job description).

Soft skills get a bad rap; especially in tech. Code has always been king, but software constantly changes. The need to be good communicators and generally pleasant coworkers will always be there. That’s why it’s important to dedicate parts of your day to improving those skills that don’t involve code. No matter how great of a dev you are, you aren’t going to to be nearly as successful if you are difficult to be around. Here are a few soft skills crucial to working in tech.

She covers four major topics around these "soft skills", what they are and what you can do to help improve them:

  • Being Accessible
  • Solving People Problems
  • Keeping Your Ego in Check
  • Considering the Big Picture

She ends the post by reminding developers that code is only "one part of the machine" and that by developing soft skills you can much more easily further your career as a developer, regardless of how amazing or clean or manageable your code may be.

tagged: developer softskill accessible people ego bigpicture considerations opinion

Link: https://dotdev.co/not-about-the-code/

SitePoint PHP Blog:
Can 9-to-5 Developers Be Good Developers?
May 04, 2017 @ 12:42:25

On the SitePoint PHP blog editor Bruno Skvorc has written up an article that wonders if 9-to-5 developers can be good developers.

While picking talks for the conference he’s organizing, James Titcumb recently tweeted that well known speakers get picked over others because, among other things, they’re reliable (i.e. they don’t cancel). I would argue that “among other things” carries more weight – I believe that most conference organizers pick such talks and speakers because they like to play it safe and fear risks.

Bruno gets into some of his own opinions about conferences and speaker selections first, noting that he sees a lot of organizers "playing it safe" with topics and speakers (and the idea of "intellectual diversity"). He then talks about the 9-to-5 developers out there that haven't been exposed to a lot of these "safe" topics because they don't branch out of their corporate bubble and attend conferences. He ends the post reflecting on one of the most used excuses for not branching outside of work hours - time, it being a "precious resource" and ideas about balance.

tagged: 9to5 developer good conference speaker opinion time

Link: https://www.sitepoint.com/can-9-5-developers-good-developers/

Robert Basic:
Open source taught me how to work with legacy code
May 01, 2017 @ 09:36:29

In a new post to his site Robert Basic shares how some of his work on Open Source projects taught him how to better work with legacy code.

Contributing to open source projects has many benefits — you learn and you teach, you can make friends or find business partners, you might get a chance to travel. Even have a keynote at a conference, like Gary did.

Contributing to open source projects was the best decision I made in my professional career. Just because I contributed to, and blogged about Zend Framework, I ended up working and consulting for a company for four and a half years. I learned a lot during that time.

He shares some of the things that open source taught him about working with code and how it relates back to legacy code (including how to find his way around). He also tries to dispel the myth that all legacy code is bad and was "written by a bunch of code monkeys who know nothing about writing good software." He points out that, at the time the code was written, the changes may have been the best that could be done, it might be a necessary workaround or it could be an actual bug that needs fixing.

tagged: opensource legacy code opinion experience codemonkey

Link: https://robertbasic.com/blog/open-source-taught-me-how-to-work-with-legacy-code/

SitePoint PHP Blog:
How Privileged Are Programmers? Are You a John, Too?
Apr 25, 2017 @ 09:31:16

On the SitePoint PHP blog Christopher Pitt has written up a new article, a story about "John" a developer caricature that's all too familiar in the development world and how you can grow up from "being a John". It's all based on Christopher's own experiences too.

John was a developer. To be specific, he was a young, white, straight, young, self-taught developer. He wasn’t rare, but he was special. John grew up with a couple parents, who paid for everything he needed.

[...] John got average grades, but it was ok because [according to mum]; “he’s just bored of schooling, and too clever”. He walked right out of high-school and into a programming job. The pay wasn’t great; only enough for a small apartment and modest groceries [for one]. In time he’d earn more. [...] Over the years, John quickly got bored of programming. He loved the thought of the career, but it was all so boring. He moved jobs every year or so, and only then when his idiot bosses stopped seeing how much he mattered to their company.

He talks about his own past, how he realized he was a "John" and how he made the conscious decision to grow up and out of that situation. He talks about those being born into comfort and how they're not always forced to grow up or to really struggle. He mentions other common "John" points of view ("we can always just move jobs" or "meetings are just a distraction"). He's angry with himself for seeing so much of his previous life in these examples. He's also angry to see these same patterns in other developers around him, other "Johns" that treat him the same way with excuses, failed promises and delays.

I think of all these clever little things I could do, to force John to work. All these processes and mantras and check-lists. Then I despair. The only thing that’s going to make John realise he is wasting away is wasting away enough to fall through his safety net. He’s going to have to grow up on his own, and maybe then he’ll pay it forward to his future employers and clients.
tagged: john programmer privilege example opinion experience

Link: https://www.sitepoint.com/how-privileged-are-programmers-are-you-a-john-too/

Stefan Koopmanschap:
To Exception or not to Exception
Apr 21, 2017 @ 16:21:47

In the latest post to his site Stefan Koopmanschap offers some advice on when to use exceptions and when to avoid them (the result of a recent Twitter discussion).

I recently found myself in a discussion on whether or not exceptions could be used to control program flow in software (specifically in PHP applications). That triggered me to post a tweet:

Exceptions should not be used to control expected application flow. Discuss.... @skoop

This triggered quite a bit of discussion, which gave me a lot of input on this topic. I want to thank everyone who joined that discussion for their input, which was really valuable. In this blogpost I'll do a summary of the different arguments in the discussion, and give my opinion on this.

He goes on to define the term "program flow" and how that relates to the idea of using exceptions to control it. He then talks about naming things, the "intent" of your code and how the right names can make your code clearer and easier to maintain.

tagged: exception flow program naming opinion

Link: https://leftontheweb.com/blog/2017/04/21/to-exception-or-not-to-exception/