Category Archives: Business and Clients

Job hunting and interviewing

I’m distilling what I’ve learned from almost 40 years of job hunting and interviewing, both as a candidate and as an interviewer. I have experience with programming jobs both in and out of the tech industry, and 10 years freelancing.

My experience ranges from big companies to startups. Big employers will have a more defined process (and it will prove harder to bypass). Smaller companies and startups generally follow a less formal hiring process.

Starting the job search

Posting résumés (or CVs) online and sending out lots of emails may help with the numbers game, and if you have in-demand skills it can’t hurt to get your name out. In most cases a more targeted approach works better.

  • Identify companies you want to work for.
  • Learn as much as you can about them.
  • Use your contacts to give you leads.
  • Work with recruiters if necessary, but only with someone you feel comfortable with.
  • If you live physically close to the company try to meet people who work there. Go to local meetups and user’s group meetings employees might attend.
  • Ask all of your friends and professional contacts if they know someone at the company. I’ve hung around offices at lunchtime and approached people at nearby delis, asking if they work at the target company, and if I can join them. Don’t stalk employees, but there’s nothing wrong with asking people about the place they work — people usually like talking about themselves.
    Continue reading

PHP MVC: Maintenance Very Costly

I mostly work on legacy web applications in PHP + MySQL. Usually the original developer is not available, so I have to figure out the code so I can fix problems or add features. For a long time most of the PHP code I worked on was written in the classic PHP style: URLs for each page, PHP code and HTML (and Javascript) all jumbled together, business logic and presentation mixed in the same file. A few years ago I started to see more MVC-style code based on frameworks like Zend, Symfony, Laravel, CodeIgniter, etc. I thought this was a good thing, and that maintaining PHP code that was based on an MVC framework would be easier. My experience, however, has been just the opposite. The classic PHP style is easier for me to understand and refactor even when it has degraded into spaghetti code with PHP and HTML mixed together. It’s easier to work on classic PHP, even badly-written code, because everything you need to know to follow the request/response flow is in one place and reads top to bottom. By comparison trying to understand the thought process behind an MVC application, with the OOP baggage it usually entails, is an order of magnitude harder, and the MVC/OOP code is not necessarily higher quality, more maintainable, or more reliable.
Continue reading

The things you need to know to do web development

Here’s a list of things I know, or at least know about, as a web developer. I’m sure I’ve left a lot of things out. Web development is a large and complex collection of technologies, tools, languages, protocols, and services. I started programming for the web back in 1995, so I’ve been able to adapt to changes and learn new tools as they were released. If I had to learn web development from scratch today I’m sure it would take me a long time to master even a few of these things.
Continue reading

Why don’t software development methodologies work?

I’ve worked on big projects, small projects, in huge teams and by myself, in fossilized federal agencies and cool Silicon Valley companies. I have learned and used at least twenty programming languages. I’ve lived through waterfall/BDUF (big design up front), structured programming, top-down, bottom-up, modular design, components, agile, Scrum, extreme, TDD, OOP, rapid prototyping, RAD, and probably others I’ve forgotten about. I’m not convinced any of these things work.
Continue reading

The joys of maintenance programming

In the old days when I started programming, green programmers trying to build their skills and get experience started out doing maintenance programming. Only the old hands got to write new code. The newbies cut their teeth debugging and fixing musty old code that still worked for the business. I’ve done my share of new development, but today I do maintenance programming almost exclusively. After working on way too many failed ground-up “green fields” projects I prefer to debug, fix, and enhance production software. I like working with real users rather than making up “use cases.” I prefer building confidence and making my clients happy with my work rather than arguing with them about features, specs, budget, and schedule. I like having a prioritized list of well-defined tasks that refer to existing code rather than trying to blue-sky specifications. I like charging by the hour instead of by the project, and not having clients balk at my rate.
Continue reading