Christian Maioli M.

🛠 Web development and 🖥 computer programming

Author: Christian Maioli Mackeprang (Page 2 of 2)

Being a versatile hacker is becoming more important than knowing frameworks

Back around 2013, the term Full Stack developer started to come up in job descriptions and blog posts. Companies were realizing that hiring developers with expertise in only one language just wasn’t enough anymore. A web developer that can handle a variety of tasks and environments is considerably more useful, and was starting to become the norm.

In spite of this, knowledge about web architecture itself did not become widespread. Many developers have been building websites without having a good grasp of how things work behind the scenes. Web forms, caching, the HTTP protocol, Apache. All of these were secondary good-to-haves.

How e-learning affects the job market

Perhaps as a consequence of the online learning boom that had started a few years earlier, the self-taught web developer knows surprisingly little about the web’s underlying technology. Language-oriented courses cannot cover the complete web stack, and students will end up clueless about what an htaccess file does, or how to restart a Unix daemon, or how the different types of POST encoding work.

What is a full stack developer supposed to know, anyway? Job descriptions frequently mention combinations of frontend and backend technologies such as JavaScript and Node, PHP and jQuery, Angular and Spring, and many others. In reality there is a significant amount of information outside those realms that would improve someone’s ability to build a website, and gone are the days when you could stick with what you know and make a career out of a single technology.

The future of web developmentIf sticking to your guns won’t suffice anymore, then what can we do, and how can we keep up with the exponential multiplication of web libraries? There is so much software being released today, that the number of possible combinations between technologies is increasing very rapidly. This combinatorial explosion will drive software development into a more ad-hoc territory. Your chances of knowing how to integrate two random libraries X and Y are ever diminishing, and any help that googling can provide is diminishing at the same rate. The window is about to close, and a time will soon come when we’ll be required to figure these tough problems out on the spot, every time. Not something for the lazy ones among us.

Hackers: the antifragile programmers

I was introduced to this very interesting concept in an article by programming rockstar John Carmack. It’s described in the following quote from the Antifragile book:

“Just as human bones get stronger when subjected to stress and tension, and rumors or riots intensify when someone tries to repress them, many things in life benefit from stress, disorder, volatility, and turmoil. What Taleb has identified and calls “antifragile” is that category of things that not only gain from chaos but need it in order to survive and flourish.”

This idea reflects the attitude shared by those that used to be called hackers. Today the word has a negative connotation, but in the early days, it referred to a person with a certain attitude towards technology. As defined by the jargon file, a hacker is: A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary.”

Antifragile - Things that gain from disorderThere was a time when looking things up on Stack Overflow whenever you had a problem just wasn’t an option, and many pieces of software had unreadable documentation, if they had any at all. I remember trying to fix a sound card issue as a kid, and reading the card’s manual, only to find assembly code listings there, with interrupt codes and all. That is the environment where hackers thrived, and that’s what we are going back to, sooner or later. If your first instinct when dealing with a complex issue that affects multiple technologies is to start with a Google search, you should reconsider your working habits.

Granted, being too curious can many times lead you down the wrong path, especially in the corporate environment where time is always short. As an example, it can be very enlightening to write test code for the basic use cases when learning about a new library, but coders looking to impress the boss will take the more pragmatic approach of copying the examples from the documentation, fully unaware of how they work. Giving value as a developer requires a certain amount of skill in time management and in setting expectations, as to allow you to seek the knowledge you need and to save the company money in the long term.

Rethinking the roles

How do you find the hackers? You need to find someone with a particular mindset, the particular curiosity and persistence that I’ve described. This has nothing to do with analytical intelligence, or with being able to memorize a particular set of academic algorithms, so whiteboard coding is out, and Fermi estimation problems don’t look too promising, either. Ask a candidate what he likes to do on his spare time, or what fun projects he worked on as a hobby, and you might be onto something. I have met many programmers that don’t write code in their spare time, and that can sometimes be a factor that tells you that they just don’t enjoy it. Look for clues which reveal their personality.

If you’re a developer, you might be worried that you don’t have that kind of drive or curiosity yourself, so what can you do about it?

Here are some pointers:

  • Whenever you have to google some error message or problem, read all the answers. Get as much context as possible on your problem, and do not be satisfied just with having come across a solution.
  • Learn about the technology, but also about the trade-offs that were made during its design and development.
  • Ask yourself what it would take for you to consider yourself a “complete” developer, and write down a path for you to get there.
  • Do what other people don’t like doing, go where they don’t want to go, and often enough you will be enlightened by the experience.

Software development is growing fast. Learning to code is easier than ever, and soon enough we will be in a survival of the fittest environment. But the guy that makes it is not going to be the guy that first learned about the cool new framework. It’s going to be the guy that asked himself what’s new about it, and what’s different this time. If you want to stay up to date with technology stacks, then stop worrying so much about being up to date, and start hacking.

Note: this article first appeared on TechBeacon.

The other kind of JavaScript fatigue

People have been talking about JavaScript fatigue lately, referring to how we’re continuously having to learn about libraries that don’t usually last very long.

I think this discussion evidences how good programmers cannot be lazy people. You have to get a liking for learning new things. Its not that big of a deal, being forced into it: at worst, you’ll become better at identifying good libraries and clean software architecture. Embrace change, and it will make you a better developer.

There is another kind of JavaScript fatigue which doesn’t have as many positive elements to it, and it hasn’t received as much attention. I want to talk about it because I believe it is talking a toll on the JS ecosystem in particular.

Richard Stallman envisioned free software as an environment where people shared their code and other people would improve on it and this would gradually drive progress in the software world in more ways than a closed source environment ever could. I think there are some requirements for such an ecosystem to work properly. A certain balance has to be maintained.

The Cathedral and the Bazaar, which should be a required reading for any open source developer, also hinted at this problem when saying that good programmers know what to write, but great ones know what to rewrite (and reuse).

JavaScript as a language does not have the correct focus that is necessary for that to happen. It is simply far too easy to create a new library or package, and since anyone can do it in a few seconds now, this generates a lot of noise. The language has even evolved to make it as easy as possible to wrap a mess of DOM-manipulating stateful code in a couple of export lines and ship the module to the world.

It is just too easy now to share poor code

Think about the process that you undergo when you want to find a package that solves your problem. You search GitHub, or the npm registry, see what is popular for that, take a look at comparisons between the top candidates, maybe check which ones have unit tests, good code size, reasonable architecture, some minimal documentation, responsive project leaders… it can take a hours, even days, to decide.

The forgotten edge cases

Recently I needed a library to build query strings, just a small one so that I wouldn’t have to include jQuery just for that. After a couple of hours of research, I had found several candidates, but it quickly became evident that even though they were working and updated libraries, none of them was able to handle nested objects and arrays properly, in the way that jQuery could.

If you’re familiar with the 80/20 rule: edge cases are the 20 of the job that takes 80% of the time, and unfortunately most programmers are not going to put in the effort if most of the benefit of releasing their library has already been garnered. Writing complete and bug-free programs is challenging. Sharing poor code is not. Slap a cool animation on your Readme file and everyone will assume your project is awesome.

There are upwards of 200,000 JS projects out there, with language features that focus on increasing that number, and tooling that makes it even easier still. It’s easy to share bad code, and hard to identify and improve it.

Oh, so you’ve spent a couple of days fixing that bug on the library you downloaded? Great job, and I hope you remembered to manually check how active the project is, and if they accept PRs, and if a pending PR doesn’t already fix the bug. Project maintainers don’t have enough tools to make their jobs easy and, unfortunately, the tools that they have are often complex and off-putting.

Consider how difficult it is to keep track of which forks are interesting, even though making a new fork only takes the click of a button.

In truth, some tools have been created which aim to facilitate writing good code, such as linters, code checkers, and so on, but they are not nearly as numerous, and building tools to parse ASTs can be tough. It’s an uphill battle.

An ode to productivity

Programmers love being productive. Once you learn that a couple of lines of code can save you hours of work, you might fall into a trap of believing that productivity is the end goal and any library or framework that makes you solve problems faster must be great. In fact, many people believe this, and tools that simplify your work will often become fads with many people swearing by them.

This can go so far as to reach project managers and recruiters and get them to actively seek people who have experience with the current trendy framework, because all the top tech companies are using it, and their developers swear by it, so clearly it must be good.

This drive towards productivity is the cause for the existence of an increasing number of build tools, code generation tools, and services which aim to make shipping as easy as possible, and nobody will question if you should be shipping your package at all.

Top result from SO disregards the most common edge case

The fragmented nature of large open source ecosystems has become evident since the advent of Android. It’s a far-reaching issue and it is also self-reinforcing because languages with smaller communities such as Go and Nim don’t yet suffer from it, and that makes them more appealing, leading to fragmentation on an even larger scale as developers rally to greener pastures.

Fragmentation is like a virus which is driven by the human passion for creation, and we need to join forces and actively fight it if we are ever going to stop it.

Remember Google’s Polymer? Angular 1? Express? Perhaps the creators of these kinds of tester projects which get abandoned if they don’t pan out should be more transparent about their intentions. After all, misleading thousands of users does not generate a positive attitude toward open source, and can lead to bitterness and more fragmentation. [Edit: I’ve been called out for this statement, but just look at how Google is abusing open source to keep other companies under their belt (downright scary article)]

Instead of nurturing narcissistic language ambassadors that drop their projects like they change fedora hats every time they get a new idea, let’s focus on organized efforts and building a sense of community. Human progress is not going to happen by default. That was not the case with clean energy, or with quality education, and it will not be different with open source fragmentation. These problems require active monitoring and group effort.

Writing good code: how to reduce the cognitive load of your code

Low bug count, good performance, easy modification. Good code is high-impact, and is perhaps the main reason behind the existence of the proverbial 10x developer. And yet, despite it’s importance, it eludes new developers. Literature on the subject usually amounts to disconnected collections of tips. How can a new developer just memorize all that stuff? “Code Complete“, the greatest exponent in this matter, is 960 pages long!

Read More

Project delays: why good software estimates are impossible

Rubik's cube world record

Rubik’s cube world record

Have you ever tried to solve a Rubik’s cube and been unable to complete it? I once tried several times during a long bus trip and felt pretty bummed after failing every time. Then I learned that there are kids out there that can do it in seconds! How is that even possible?

Update: Mia Li was kind enough to offer a Chinese translation of this post here.

Unexpected complexity

When you, as a programmer, start a new project, you will often not know full well how to do it, for many reasons. But you are a professional, and you’ve completed similar tasks in the past, so you either try to figure it out, or find someone who can, and ask them how, or just google it.

Very often, you do not know you’ve found yourself in this dilemma until it’s right in front of you.

Here are some examples:

  • You have to re-implement something using a new framework or library
  • A library you’re trying to use doesn’t like the other library that you’ve been using
  • The API you’ve been integrating doesn’t do something you thought it should do
  • The framework you’re using doesn’t like unit tests and the ones it has are actually integration tests
  • You thought a model in this new framework was a singleton like in the other one but it’s not

Estimating unexpected complexity

“Can you estimate these new tasks for me?”, asks your boss. Remember that Rubik’s cube you couldn’t solve? How many hours do you think it would take you if you gave it another shot?

“What? Two days?”, “But our previous developer could do that in a couple of hours! No way it will take you that long.”

There is actually an algorithm you can learn that, with practice, will help you solve a Rubik’s cube very quickly. But you don’t know that right now, and there is no way to know that you are going to find that, and that it won’t really take you two days to figure it out.

Complexity is cumulative

There more tasks a project has, the more likely that you will run into this kind of situation, so if you do not severely overshoot your estimation, there is really no way to be sure that you’ll deliver on time.

Let’s do some crude napkin math to visualize this a bit better. Say that you are an experienced programmer, and you only run into unexpectedly complexity about 5% of the time. If you are starting a new project and split it up into 10 tasks…

1 - (1 - 0.05) ^ 10 = 0.40

Or: there’s a 40% chance that you will run into a complex task, and blow your estimations for this project.

Why are projects always behind schedule?” backs this up with more math and with actual project metrics over 70,000 hours of work, so check that out if you’re interested.

Creative vs mechanical tasks

“The creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line.” – T. Bollinger

Einstein trying to estimate a project

Einstein trying to estimate a project

The problem comes down to the difference between tasks which require a lot of thinking, and routine tasks which you already have some practice with.

In “Software has diseconomies of scale“, there’s an interesting argument being made about what this difference has on productivity. For creative tasks, the more of them you have, the more time each one will take, whereas mechanical tasks have the opposite effect, they can often be automated to some extent.

It doesn’t seem possible to estimate these creative tasks with reasonable accuracy at all, and not even proficiency or experience can help you here. Think about it, would it really have made sense to ask Einstein how long he would take to find a unified theory of physics?

The best you can do is estimate based on historical metrics which, in software as in the stock market, is not worth very much.

Further reading

Mathematical limits to software estimation

A successful startup crash course taken from a Reddit AMA

I’ve just read this AMA by Bryan O’Neil, a serial entrepreneur, and he was giving some very sensible advice for anyone trying to get a small business going.

He answered almost every single question, too, which is unusually nice in an AMA.

Here are some of the highlights:

Q: If you’re starting over tomorrow with only $500 and your knowledge (no contact list), what’s your plan to start generating revenue?

A: I’d pick one of the many ideas that I’ve jotted down but haven’t had time to execute, throw together a landing page for validation purposes, run $100 worth of AdWords traffic to it to validate the idea, and assuming the market accepts it, spend a week working full time on building buzz around it.

If the idea involves something that I’m personally not overly experienced in and I don’t have the budget to hire help then I’d also look for a partner to join me in building the venture. With no existing contacts, I’d turn to startup communities to find one.

  1. Put together a landing page (use tools like Leadpages or Instapage)
  2. Create an AdWords campaign and send some traffic to your newly created landing page
  3. See if it converts

What many people don’t get is that for a test like this you don’t need either a product/service (your landing page can just lead to a “sorry, we’re not open yet” message after the payment link), nor a massive budget, as a $100 test campaign will already give you a whole bunch of information on whether your idea is likely going to get traction.

Q: How do you measure conversions? By seeing what percentage of people leaves their email address to be notified of the launch?

A: Never. A “free” conversion is not a conversion.
What I usually do is I build an ACTUAL landing page, with a dollar figure, and see how many people are ready to proceed to the payment page. The payment page, however, doesn’t exist – it just forwards them to an email signup apologising and saying your product isn’t yet available.

This is the ONLY way to properly measure conversion, as regardless of what people say, things get very difference once you ask them to pull out their wallet and type in their credit card number.

Q: How would you define “building buzz around it”?

A: The reason why most people are vague about “building buzz” is that it’s extremely different depending on the industry that you operate in.

With all that said – whilst “buzz” is good and gets you some much needed attention and feedback, I personally prefer paid advertising any time of the day. A product that requires “free traffic” to get sales is typically operating on a flawed business model.

Q: What is the best way to cut through the BS and get a site to be generating actual revenue?

A: Direct sales, affiliate marketing, product sales, service sales, etc are monetisation methods / business models, and typically have little to do with whether your site will generate or not. It would be like asking “if I want my business to start making money should I build a laundromat or a petrol station?” – there’s no correct answer.

You can generate revenue with any business model so long as what you’re offering is on demand and you’re good enough in getting it in front of people. There’s no magic pill, and whoever says there is, is quite frankly full of it.

Q: What can I do today to take a blank slate site and make it sellable?

A: One of the biggest myths in the online acquisitions industry is that content, clicks, traffic, design, backend software is worth something — in 99.99% of cases it isn’t.

The one and only thing that buyers look like when buying a business (online or offline) is its revenue. If your site doesn’t make any money then no-one cares how much traffic it gets or how much of original content there is on the site – if it was worth something then in all likelihood you’d already be monetising it. There’s a couple of exceptions to this, of course:

One is very low-end (<$5k) sites – these do tend to sell based on non-revenue metrics from time to time, as a buyer may want to pick one up simply for the sake of the ‘idea’ and to save time and money that developing a similar site from scratch would take.

Another exception is potential, e.g. cases where a site does have what it takes to generate revenue but for one reason or another it hasn’t yet been (properly) monetised, however don’t expect anybody to pay a premium in this situation as buyers will be very careful dealing with you, with most of them asking the “if it has such a good potential to make money then why isn’t it making it already” question.

Q: Do you manage all of the creative and copy yourself?

A: First iteration – always myself. It’s meant to be a “quick and dirty” job where the primary (and only) focus is on time. It takes me less time to write up a simple landing page than it would take me to hire external help.

Once your idea is validated though, it of course makes sense to turn to professionals and get everything done properly.

Q: How do you make landing pages to test an idea such that it complies with Google’s “Information Harvesting” terms?

A: Make sure your landing page has enough information on it, that it has all of the elements that Google wants to see (privacy policy, etc.) and to be double sure, make it a 2-part landing page where the actual form is on the 2nd page, not the one that you send traffic to.

It’s also worth looking towards Bing, by the way. They’re capable of providing quite a bit of traffic but their policies are much more relaxed.

Q: What are your most used tools?


  • Trello – for organising nearly anything, from meeting agendas to product pipelines to ideas. You need to become a “power-user” though – there are so many hidden features that are incredibly useful.
  • GoodTodo – the best ToDo list ever. Doesn’t look like much but it has two bits of functionality that no other ToDo list app that I know of has. Watch the video on their site to understand.
  • Gmail Multiple Inbox + Custom hack – this changed my life!
  • Notepad – not the Windows app, but the real thing. There’s something in writing things down the old fashioned way. Plus research has shown that you’re far more likely to remember things that you’ve written down on paper.
  • Macbook Pro, two 24″ screens and a mobile WiFi dongle with support for international roaming.

Q: What kind on knowledge do you think is most useful to learn for a beginning online entrepreneur?

A: Personally I’ve always learned as I go along, i.e. if I get stuck with something then I educate myself enough to overcome the issue. This applies to practical things.

In terms of theory, the most important thing to master is the ability to execute quickly (read The 7 Day Startup: You Don’t Learn Until You Launch by Dan Norris) – as the speed at which you get your ideas into a stage where you can accept payments will often define your long term success. I hate famous quotes but … as Reid Hoffman put it: “If you are not embarrassed by the first version of your product, you’ve launched too late.”

Think about it: if it takes John 60 days in average to get from the idea stage to the launch stage and Andy a year to do the same, then in 10 years John will have launched 60 ventures whereas Andy has launched 10. Now, if 10% of their ventures actually succeed (probably a fairly accurate figure in the online business scene), John will have 6 revenue-generating businesses by the end of the decade and Andy will have 1.

In hindsight, I wasted many good years in the past on “trying to make it perfect”. It was only when I decided to get rid of my perfectionism and concentrating on launching quickly when things started taking shape.

There are several other questions, although most of those are related to selling a website and how much you can get from it. Take a look at the complete AMA post for more.

Page 2 of 2

Powered by WordPress & Theme by Anders Norén