Notes on my first PHP job

This is kind of long and somewhat repetitive. That's sort of the idea, to show where a few bad decisions or structures will pop up everywhere, over and over.

Background

As a kid I dabbled in BASIC and Comal80 on a Commodore 64. The next computer was a 23 kilo 286 which managed Win 3.x over DOS and taught me batch scripting, then came others and I picked up some C, HTML and Linux before high school. There I was taught some Java, C++ and more web development, including standard SQL and JavaScript. The impression was that the schooling was abysmally bad and that adults knew nothing about computers, especially since my 'thesis', a project consisting of a small OpenGL engine at the end of high school, was graded solely on the documentation because the teacher didn't manage to get a C++ compiler and run it.

So I vowed to never make a living as a programmer and only use my interest in computers for evil. Instead I played around with a little cracking and a lot of malicious input into web apps over the next years, in a kind of grey hat not-very-legal manner.

Fast forward some eighteen years and I have changed my mind. At uni I studied some theology and law but never took a degree, in my spare time I passed through Python, Common Lisp, Clojure and then to the more obscure post-LISP language picolisp. This led to an offer I couldn't refuse, emigrate to the european south and work with modernising legacy PHP in an addiction business.

Having no ethical issues with profiting from semicompulsory behaviour, I wouldn't turn down Twitter either, and wanting the experience I jumped on the offer and relocated. At the time I had also found that my home country was turning weird and dangerous to leftists so it was attractive to leave and watch from a distance. It turned out to be great fun, absolutely terrifying and a very valuable experience.

Organisation

When I arrived I found myself in a group of roughly twenty developers including two bosses in one room where managers from elsewhere in the company considered it a virtue to take part in micromanagement of development. The result was an interesting, fragmented development process where specs and UX analysis seemed taboo, more or less replaced by vague instructions like 'port this' and 'add this feature' and a lot of silence following questions and suggestions.

After watching one boss integrating with a third party API for a couple of days I started getting assignments and worked away on them. Weeks passed without constructive feedback and it turned out that code review was not a part of the regular development work, and also that devs were explicitly forbidden review among peers.

Instead a kind of code review was implemented after one of the bosses moved to another country and started working remotely. However, it was done by skimming through commit diff snippets and commenting on string concatenation or recommending hands down bad coding practices. Sometimes these practices were implemented instead of the present, more adequate solution as to avoid friction or conflict.

Since every developer chugged along alone with little contact inbetween bosses also had to repeat themselves quite a bit, telling the same thing to different people, something which appeared to be inconvenient and wasteful to me.

The lack of structured planning meant deadlines didn't exist, it was rather a culture of quick fix driven development and incremental design. No cohesion in the team parallelled with little cohesion in code output, also this an interesting choice of managerial doctrine.

A result of this was that the code bases were quite irregular. One person liked warts on variables very much and no one else did. Another thought PHP lacked web templating and invented some in PHP, arguably the worlds most widely adopted web templating language. One had failed at creating REST API:s for years and adopted GraphQL instead, and thus coerced others to do it as well. Some liked Eloquent while others prefered passing in strings to Fluent QB for raw execution, yet others wrote a custom layer on a little of both.

When there was quitting and laying off ahead it was obvious but not spoken of, it seemed like the bosses thought the rest of us didn't notice anything. It meant quite weird moods among some colleagues and a lot of loose rumour when someone no longer worked there. Perhaps this was the idea, I found that hard to tell.

It took several months before I was first given a private talk about issues and performance, where I brought up concerns regarding this and some SQLi:s I'd found. I was told something something company policy and that we tend to patch such vulnerabilities when they were found.

Leadership by fear, anxiety and alienation can be profitable but only in sectors where quality is a non-issue, where machines are the producers and humans are used for pulling levers or something similar. It seems it doesn't translate very well to the art of programming.

Lessons learned

• If your boss is more impressed by LoC output or obedience than code quality and ability to reason about it, start looking for another job because when this becomes an issue you're going to get fired rather than promoted

• If every branch in a repo has a style of its own you'll learn a lot, but it will also slow down bughunting a lot unless it was you who wrote the code

• If there is no constructive feedback on your work you'll have trouble performing well

• A manager has the power of the payslip while you have the power of trust, hence you'll be more likely to be fired if your colleagues start trusting you more than their managers

• Don't work unpaid overtime, and if you did anyway, make sure to tell your superiors you have so they know that they owe you more than they thought

• When confronted with incoherent code bases consistently write in your own style to the best of your ability and try to make sure the result is good, rather than ask superiors or colleagues about it

• Listen closely to what your colleagues are saying about past employees and what resulted in them no longer working there, this can help avoid sudden changes in your employment

Code

What I thought would be modernising legacy code eventually turned out to be conservation and wrapping of it in more and more projects. The core application was an elderly publishing platform rewritten in the details over the years but never refactored. A term that happened to be used as a synonym to 'changing existing code' rather than the common technical meaning at that workplace. At first this was very confusing.

This core was written in a procedural style with some OOP on top, ruminated for many years and having a high degree of interconnectivity between files and functions. The resulting complexity turned out as big red circles in PHPmetrics and quite challenging to anyone, regardless of previous experience. What had been described as microservice architecture was rather wrapping of bulky frameworks around new or old instances of this.

At some point when developing new software one needs to make some strategic decisions about what kind of programmers one wants to write code for. If one is the only one at a company who appreciates higher-order functions and currying as a way to break down problems one should avoid it and make a series of classes and interfaces instead.

On this issue I found no leadership and struggled quite a bit while figuring out that this was my issue and that I had to try and predict who might read my code later on. Not having a common idea of what kind of software shop the place should become seems to be bad for productivity. Instead the environment was one where old-timey for i < count(input) i++ was a viable pattern even though foreach was introduced in PHP 4 and a code review comment could consist of a demeaning comment about education and a link to the PHP manual on strings. Because apparently the problem with pasting unvalidated input into database queries are whether it is done with single or double quotes.

While the absence of strategic discussion and peer based code review together with quick fix driven development makes it imperative for a junior to quickly learn new tools and code patterns it also seems like it has some cost in the long run, since victorious debugging becomes reserved for the ruthless one cannot just assign anyone to a ticket without risking that they'll spend a week in circles.

Increasingly I got better at quickly judging the code and found more and more serious issues to add to my private bug database. For some reason there was no common one. These findings alarmed me more and more, since I thought it too risky to have some of them in production. When sounding the alarm I was however met with an indifference I had not anticipated, and later I learned that some of these had been known for years and that those who made a fuss consistently had been laid off.

Lessons learned

• When confronted with incoherent code, relax and follow the execution over and over in your mind until you understand it and why the output is as it is

• Thinking in incoherent code is demanding, never skip lunch because you'll get nowhere the last hours of the day

• If you aren't getting good criticism of your code you need to invent it yourself

• The worse the code, the more power is needed in your tooling as well as a solid understanding of command line scripting

• Coding is an art so insensitive comments about it are sure to hurt, use this might wisely and with consideration

• Don't give up bughunting until you have spent a fair bit of time breaking the application in creative ways

Conclusions

I strongly recommend anyone willing to do PHP but lacking work experience to take a job at a place that will hire you on just a few lines crappy code and some talk about knowledge in areas that have nothing to do with the business they're in.

You'll learn fast, learn a lot and see things that you otherwise would never understand how much you need to avoid until you've done the same mistake yourself and messed up bad. And this is very valuable, impossible to learn on your own (arguably you could pick some up in OSS dev) and will be with you for the rest of your life as a programmer.

Next I'll be more useful and show the toolchain I got comfy with.