Let’s get right down to it: many managers worry about whether or not their employees would work or goof off if they were allowed to be remote. It’s a huge fear; it requires faith in your employees, since you can no longer see them or glance at their screen from time to time. Employees are expensive to have on board, so you’d rather they spend their time actually solving problems rather than playing Sudoku or watching Star Trek on Youtube.
And yet, there are dozens if not hundreds of companies that are partially, mostly or completely remote. From Automattic to Github, these companies have figured out how to get things done while partially to fully remote. And the good news is, so can you.
The biggest complaint people have about object-oriented design is where they put all the “glue code” that ties together a bunch of objects and makes them work well. For many, this place is the controller, but as I’ve covered before, most of this logic belongs in the model. In fact, the model should be where all business logic resides. And yet, it can still seem difficult to figure out precisely how to manage all of these behaviors in one place and still follow the best practices of object-oriented design and development.
But there is a way to accomplish this that won’t make you crazy. It’s accomplished by making use of “services” – bits of code that act as the “glue code” for all the different objects that have to operate.
My recent post on the reasons estimates suck generated some interesting questions about the management of client work, specifically related to client expectations and the “need” to offer an estimate of completion or cost to the client. Some of us are lucky enough to have internal clients to whom we can refuse to estimate; others are working with external paying clients who really want an answer to the question, “when will this be done?”
There are some ways that you can avoid offering estimates and still make your clients happy. The solution lies in figuring out precisely what question your client is asking when they ask “how long will this take?” Clients are asking this question usually for one of two reasons: because they have a business need that is unmet and they need this ASAP, or because they are trying to control cost.
Somewhere, right now, a project manager is compiling estimates on a software project and coming up with a completion date based on “velocity” and “scope”. When they’re done, they’ll take their completed work and show it to their boss, who will look it over, and set a “hard date” for delivering the project. There will be a team meeting, the developers will be gathered, the plan will be presented to great fanfare, and everyone will go off to work, expecting that they’ll actually meet the hard deadline in three months.
Three months will go by. The deadline will come and go. And in most cases, the deadline will be sorely missed.
In the debate between developers and their employers, fixing technical debt is often seen as a cost center, a time suck that takes away from feature work. After all, when there are features to ship and clients to satisfy, taking the team off such projects so that they can rewrite what already works is seen as silly, costly or foolish.
But smart employers recognize that technical debt is more than an annoyance or a cost center. They recognize that technical debt has a chance of costing them good developers.
Dealing with errors is one of the most frustrating and challenging parts of developing an application. Nobody likes to think about their application in a failure state, and there’s nothing more deflating than writing a bunch of great code, and getting a message that you forgot a semicolon on line 4.
After trying a few packages and becoming frustrated with the nature of the available packages, I decided to write one. I called it BooBoo, because everyone makes mistakes. BooBoo is a package for error handling in PHP.