Coder For Hire

I've been programming computers since around 1983, starting on a Commodore VIC-20 with 3kb of RAM. I taught myself BASIC and 6502 assembly on the Commodore 64. Next up was the Commodore Amiga before finally -- reluctantly -- switching to the PC in the mid 90's.

I've been working as a professional freelance programmer for almost 20 years now. My expertise is traditional web development, i.e. fullstack LAMP. Besides the classic "must have's" of web development -- LAMP, JavaScript, HTML5, CSS3 -- I'm experienced in Python, C/C++ and Java. I'm also always keeping an eye on Go and Rust. I toy around with about every game engine I can get my hands on and have a good grasp of UE4 and Godot.

I like to keep my toolbox as open as possible, in more than one sense. If I have the choice, I prefer Open Source software over proprietary software and think vendor lock-in is one of the capital sins of software development. My personal development philosophy is radical pragmatism and simplicity. I think every programmer should have at least some experience in embedded development just so they really learn about working in highly restricted environments and the true inner workings of a computer. Overengineering is rampant, especially in web development where toolchains change every three months and are replaced with ever more levels of abstraction layered upon abstraction. I avoid -- shun, even -- trends and hypes. Whatever bad some people might think about PHP -- and they're definitely often right -- the fact of the matter is that PHP has been around for a long time and is here to stay. And not only has it gotten exponentially better, more powerful and more performant with every release, it's still very backwards compatible. Something that can't be said about many of the newer software stacks.

Coming back to overengineering though, I also notice that today's PHP developers have bought into the same framework hype that's holding JavaScript development hostage. PHP is not just a language, it comes with a lot of built-in features. To paraphrase Rasmus Lerdorf, creator of PHP, we lost when people started using PHP -- a templating language -- to develop templating languages. I don't think all frameworks are unnecessary, but I do think it makes much more sense to leverage all of PHP's built-in features before reimplementing half of them in a framework that only leads to the other big captial sin of software development: unchecked dependencies.

Same goes for HTML, CSS and JS. Stop implementing frontend frameworks that do things CSS3 already can do on its own. Stop twisting JavaScript into something completely different before taking full advantage of the power of vanilla JavaScript. Again, a good framework that doesn't get in the way of doing actual work is a blessing. I'm using W3 CSS as my go-to CSS framework. It's a fraction of the size of other CSS frameworks, comes in a single file, doesn't need any external dependencies and still packs all the functionality a good CSS framework should have. Because it's taking advantage of CSS instead of trying to replace it.

This website doesn't use any server-side code. I've always wanted to build my own website with a static site generator. I tried many of them, found pros and cons for every one and in several cases was shocked at how much over-engineering you can pack into a SSG -- looking at you, Gatsby. I finally decided to give Zola a spin. In the end it was a toss-up between Hugo and Zola. I opted for Zola because I found the Tera templating engine a little more approachable than Hugo's Go templating. Both tools, being single binaries with no dependencies, definitely satisfy my philophy of radical pragmatism and simplicity.

Despite all of that, do you still wanna hire me as a developer or a consultant? Great, get in touch! I'd like to help you get your project up and running quickly and painlessly, avoiding unnecessary overhead and dependencies that are guaranteed to break in the next 6-12 months. Just one little caveat: please don't waste your time or mine with a phone or whiteboard interview. I understand that you need some kind of assurance that I know what I'm talking about, but interview questions are absolutely worthless. You can study for one short weekend to pass about any whiteboard test. But having memorised the textbook definition of the difference between an interface and an abstract class or writing a textbook example of pseudocode implementing Bubble Sort on a whiteboard doesn't make anyone a good developer. It is just a waste of time and goes against my philosophy of radical pragmatism and simplicity. So if it's vitally important to you that your programmers can cite textbooks, we're probably not a good match for each other.

Copyright © 2019 Matt Grandis

Powered by w3.css