The 14 Forms Of People



The checkbox people

I am one. Has a list, must check it all.

The radio button people

They find one aspect of life and identify completely with it.

The textarea people

I’d like to be one of these. The interesting ones but also potentially boring folk.

The text input people

They’re very good at oneliners.

The dropdown select people

Like the radio button people, but introverted.

The multiple dropdown select people

They appear to have options, but they’re all in the same box.

The button people

Your vegan activist which activates only when something clicks.

The slider people

They appear to be easily dragged around, but only in the one way they want.

The label people

Despite being annoying, they’re quite necessary.

The fieldset people

Natural born managers, don’t do much other than keep the flock packed.

The optgroup people

Like the fieldset people, but less lucky in life.

The legend people

The do all the work of the fieldset people.

The keygen people

The folk who know the friends of your friends beter than you know your friends.

The output people

They write useless content all over your Internets.

Are web developers any good in times of war?


Does CSS have any worth for an army officer? I personally guess not, from the front end we’ll end up directly on the front! If all your skills are about HTML and CSS you future might be bleak. Maybe some colonel will want a personal website, i don’t know like a thumbnail gallery of AK models, they’ll use and then dispose you as a liability in the attack line of some distant battle.

Damn you Erdogan! I knew a had to learn Python faster!

My Node experience could come in handy, I could spell it out as “real time services building”, that should be worth something, a war force must use real time services. OK, one point scored.

PHP? Oh my god. not really. I mean I bet the military IT guy who reviews the recruit records hates PHP. He must since he or she probably still does FORTRAN and COBOL. What, you don’t really think the person analyzing your file is some NSA computer guy? Ha ha. No it will be some low ranking person, who still uses huge floppy disks I bet!

Ruby? Worthless. No one cares for your elegance in the army, sorry. Numbers are objects … what is this, mutiny? Mixins? When you have a chain of command? Hell no!

Hmm, maybe Javascript will score me some points, because of node. I’m sure our beloved Internets will revert to text mode, as the luxury of 1 Gbps at home will be long gone. But even then, mind you, shall you ever code for the army with JS there will be no framework to have your back. In the army $ means something else and you don’t have it.

Hmm. Add to your file gulp, sass, less, webpack, react, angular, cordova, responsive, flat, canvas buzz buzz buzz zz zz zzz, when the recruit person wakes up you’ll get dispatched to washing the dishes, which is not bad.

Oh, you have Agile process experience? In the army Agile will get you court martial-ed in no time. Individuals and interactions over processes and tools? Think again soldier! Responding to change over following a plan? Gimme 20 push ups son, maybe SCRUM will sweat out of you!

I know! I’ll rephrase my vagrant pains as “virtualization of workstations for efficient distribution of software development environments”. That sounds good, sounds important.

Unlike, say, my experience setting up AWS and EC2, those are property of the US army so I’ll have to revert to booting some Apache on Lenovos again. You don’t want to tell your commanding officer the enemy’s technology is better and more practical, unless you like solitary!

I also think in case of war, finally, SVN will have a comeback. Huzzah! I mean, fast branching? Who authorized that branch? Did you get the permit to pull from master? Damn it son, do that again and you’ll cook so much oat meals you’ll be dreaming them at night.

One thing that makes me smile: can you imagine online marketers? Social media managers? What will they ever do for their country without all those cookies?

Coding shall be another solved problem


What will be to [web] development what the phone was to photography?

Machine Learning

Lauren Mendoza said it right in her Coding is over rant. But because she has the beginner’s view all over her sentences everyone got so so so mad. The problem why coding is over is not CRUD, frameworks, CMS’s or because “coding is dumb”.

Coding is over because machine learning is here to stay.

Don’t worry, no SkyNet is coming. I don’t mean computers will program themselves. I don’t mean software will pop into existence inside scary machines. I mean that the essence of the way we program computers today, by scripting their actions will gradually fade away making room for new concepts and practices which enable A.I. development.

But for now, if you worry about coding, then the first item for your concern is that coding today is a trade (a craft). It is a metaphor or compliment at best to call someone a “front end engineer”.

Engineering is the application of mathematics, empirical evidence and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes and organizations. says the wiki

Because coding is becoming a trade, a craft, coding is common, over staffed, and it requires efficiency added to it. Any trade in history went through this cycle: initial boom based on scarcity and requirement of individual skill, followed by innovation removing individual skill and scarcity. We’re simply waiting for the industrial revolution of computer programming, which today is a lot like manual labor.

Programming a computer is no different today than it was a while ago to make clothing or shoes or iron. But when technology appeared that made outputting clothing or shoes a million units per week, then it was over. In computer programming the revolution of the industry is artificial intelligence.

Do you know what should coders fear? Here is a quick list:

  • that they don’t know maths: this is what computers run on, mathematical constructs, and if your code editor is a word processor not a mathematical problem solving tool, you’re in trouble.
  • that they don’t know statistics and statistical models: in the near future about everything will consolidate and to work with big data you need modeling like you need air.
  • that they don’t understand graph theory: you are a graph yourself so you should learn about it even outside of professional endeavors.
  • that they don’t grasp recursion and functional patters: basically if all you can write is “code” you will be replaced if not physically at least conceptually.
  • that they don’t know algorithms by heart: oh the favorite whining of everyone (me included) about big co interviews, but the truth is simple: you want your surgeon to know all those darn anatomical teeny weeny parts inside of you, right? Then a person programming the brain of my online existence better know their algorithms, I say!
  • and that they don’t know python: you gotta know python. Like really, you gotta know python! 😀

In other words, coding is over unless you really are an engineer.

Fear not your lack of education, fear only your basic skill set.

I don’t know (m)any of the things above and I fear for myself because I am still trading in code. I am learning my ass off so that I will not be a deprecated resource when I turn 40 and start shouting “ageism!”. Oh, and I also convinced people to call me a manager, haha, maybe that’ll do the trick before I must go through those darn Hadoop tutorials.

Machine learning will change everything. Everything.

It will be the industrial revolution all over again but it will also revolutionize its own industry: information technology. Who will require “websites” when the computer will interact naturally in all kinds of shapes and forms? Many small businesses. Therefore coders will become one of two things: low paid workers or Swiss watch makers, in both cases nothing like what coding is today: a sellers market.

Coding is dumb?

I don’t know when or how it happened, but at some point, “IT person” became “developer” which became “software engineer”. says Lauren

“Coding” exists because of the web. Back in the dark ages before it, you had a very, very high entry barrier before calling yourself a programmer. Many abstraction upon abstraction and protocol upon protocol iterations later and you have CSS, HTML and the DOM and we have you writing “code” for “tasks”. No architecture, no pattern, no design, not even elementary understanding of underlying technology which makes your “coding” possible. Hordes of coders which get thicker and thicker by an educational worldwide effort to transform every miner into a coder, every school child into a coder, every single person into someone who can write code.

Yet, coding is required. From the perspective of software eating the world, you must mutate to digest it when you choose the fight to eat it back: that means learn to code the software. Or, you choose the flight option and quit and go to a poor warm weather country and mock us the fools who fight the invasion, indirectly sponsoring the possibility of your nomadic lifestyle. Both work.

My point is, by all means learn to code, be a coder, but expect it to be a minor achievement in your life, career and future.

Medium updated publications with common sense features, touts them as powerful upgrades

It’s so funny: a navigation bar! Links to stories! Use stories as static pages, wow! Writer profiles 🙂 And wow, check this out:

Starting today, you’ll be able to customize the URL slug of your publication’s stories on Medium. Slugs serve as a strong signal in SEO, so you’ll be able to control what you optimize for.

Did you know the slug is important for SEO!?

I don’t know, maybe its stupid of me to think like this but I couldn’t help it notice how magic works, as in wrap age old things into PR and community management speak and present them as new great “features”.

I mean is a navigation bar a powerful feature for a CMS in 2016?

Are writer profiles a powerful feature for a commercial, enterprise grade CMS in 2016?

Of course they’re not. But no one cares because the rush of recommends and viral distribution will cram hordes of publishers and writers to use sub par systems and hack them out. And it’s OK! I am here doing the same thing.

But it does point out to a huge flaw in the Silicon Valley system of MVP and fast time to market:

Everyone reinvents everything.

The good part is that, just like SpaceX’s rockets, the new Medium CMS resulting from reinventing decades of knowledge should land vertically.

The annoying part is that they don’t moderate their announcements and yell in our inboxes about innovative, powerful features. A navigation bar that hides itself on scroll. Imagine my wow!

Tech recruitment works like figure skating competitions


And it sucks. Here is why.

First you must do the arbitrary sport exercises, which have very little to do with actual skating: a lot of jumping, twisted jumping, jumping on one leg, jumping on the other leg, grab a person and throw it in the air, you know, like all these things which do not involve skates at all. Just like your whiteboarding algorithms written with pseudocode. We test athletic abilities in a sport concerned with gliding on ice, just like we test computer science in a trade concerned with programming interpreters. I mean, seriously, most jobs out there in web development do not require programming a computer, it is just scripting an interpreter to program the computer.

Then comes the artistic part. This subjectivity loaded section of the figure skating show constantly has people booing and shouting at judges. It is what we call in recruitment, finding the culture fit. The culture fit hunting is a seduction game, more than an interview. And it is wrong, just as wrong as not understanding “presentation” or “artistic” reasons for which your favorites loose.

That is why I always prefer ice dancing. I don’t even bother to watch the other disciplines. Ice dancing looks very much like, you know, skating. And no, I have no metaphor that transforms ice dancing into technical recruitment.

Too many companies want to hire the “full stack generalist”.

That is fucked up.

Becoming a “full stack generalist ”should be an aim for developers. A good developer, at some point in their professional development, will become a full stack generalist.

First of all a full stack generalist is a weak idea, an ideal state, a unicorn. Do you go and have your heart surgically repaired by a generalist physician or a by specialized surgeon? Do you know of a lawyer who is OK representing in any kind of trial or are there divorce lawyers and criminal law layers and so many other types of lawyers? I am probably the umpteenth idiot using these comparisons. There will be people screaming: it does not apply. But, in the end, seriously, be honest: if you have used for the past year the same tech 80% of your time to give 80% of your output, you are not a generalist; considering you will always be in a team, other than debugging critical production code, being full stack is of very little use.

I think recruitment would become better if people would make up their minds.

Do you want to hire system architects? Ask system architecture questions.

Do you want to hire someone who can help the system architect choose the best algorithms? Ask algorithm questions.

Do you want to hire someone who writes PHP or JS or Ruby or CSS for 80% of the time? Ask damn PHP or JS or Ruby or CSS questions.

Do you want to hire a “polyglot” because your software is a mishmash of technologies? State so in the recruitment phase, don’t enjoy humiliating specialists.

Technical recruitment is lazy.

You know why? Because a lot of candidates are self taught and very, very young and a lot of technical recruiters are self taught and very, very young. Because the salaries are high and companies assume they require “top talent” to get the job done. Really, they don’t. Most startups and corporations do well with average coders. Even Google and Facebook, with their huge scaling issues have plenty of positions where no rock star is required, yet they tend to interview each candidate as if they’d program the launch controller on the Falcon.

The salaries for average and beginner programmers are high because of the freelancing market. It is a mistake to assume it is because companies are fighting over them. Companies fight over top talent, not average WordPress theme cruncher. Sorry, I am a WordPress theme cruncher too, we all are, but some of us are top talent, full stack generalists who happen to crunch WordPress themes, they are not average.

If you learn to code believing companies will fight to get you, you will be in for a really bad surprise. Companies will not give you a job, just because you’ve done your fair share of Treehouse and Udemy. Companies use two strategies to hire. One, they leave it to other developers, wrongly believing that it is good, and most often creating “bro hoods” and sausage parties. Two, they use the same dated procedures that assume “programming” is like plumbing or, at best, engineering, creating teams of code typists. Right after you learned “coding” you don’t qualify in either of these groups: you are not a bro yet and you are too idealistic to program with Java for the rest of your life.

Everybody wants experience, passion, proven track records, A players, outstanding personalities.

This is bullshit.

Most people are average and that applies to programmers too. I have a scale: coders, programmers, developers, architects, innovators. It might be bad, so far it works for me. I believe recruitment should have a very clear picture of what it recruits and allow growth. It has been a while for example since I’ve seen anybody specifically looking for juniors, juniors mind you not graduates.

If you believe that having a person you pay a top salary to slice PSD files is OK, because he or she is a “front end developer”, you are wrong.

If you consider that a senior developer, with 10 years of hands on experience, paid at market level, should spend eight hours a day putting data into Smarty templates, you are wrong.

The plague of boredom leaves hard to conceal scars on your product.

It all starts with understanding two basic things about programming:

  1. just about anybody can eventually program an interpreter
  2. learning how to code is a basic skill just like driving a car is a basic skill

I often think about how hard it was for my father to get a driver’s licence. He had two theoretical tests, a test of driving aptitude, a night and a day exam on the road. Today its about as easy as asking for it: give me the licence, i bought a car. It’s that easy. That is exactly how it will get in time with programming interpreters. There is an amazing effort into building higher and higher level abstractions of coding. People don’t program computers anymore. There are some, highly specialized programmers who work with the machine. We work with a pampered version of it: the interpreter.

One who can reproduce with HTML and CSS a .psd file, blindfolded, while having a foreigner describe in bad English the contents of the .psd file, does not need a computer science degree. It needs to understand the web browser rendering interpreter, that is what HTML and CSS program. The better he understands it, the bigger the seniority level. The more up to date with rendering engines she or he is, the better an asset at hiring time. There.

One who can write with PHP whatever it is required in a specification: an algorithm, a data flow, functionally or object oriented, with minimal security bugs, efficiently, logically and all while implementing best practices, does not need a computer science degree. It needs to understand the PHP interpreter. That is what PHP programs. The better they understand it, the less they whine and bitch on the Internet about it, and ship fast web products that work , because that is what PHP is for. The more up to date with PHP interpreters, alternative or official, he better an asset at hiring time. Easy.

None of the above need to know algorithms by heart. In fact, I would say that the sole purpose of learning things by heart is for quick reaction time. I find that it is better to ask function names in scripting languages and to see if one knows immediately what is built in the interpreter or the SPL, that is of far more help in quick reaction scenarios. For algorithms, you need to take your time anyway. It’s like imagining that if a nuclear power plant explodes, you do a Binary search tree on a whiteboard to find the best plan.

One who writes an interpreter or, say, one who programs hardware controllers, they do indeed need a computer science degree, because they are programming computers. How many of these whiteboarded people program against a compiler? But they need the computer science degree not for knowing things by heart, but because it is required knowledge, if you want to program computers, to understand why and how computers are programmable in the first place. They have another set of problems. A 22 y.o. computer science graduate going into robotics has the same absolute value as a 22 y.o. self taught programmer who developed for the past 4 years Javascript apps and goes into web development. They have different domains of knowledge. The graduate will do sniff at web development and the JS coder will program a robot lost in callback hell.

So, to fix recruitment we need to:

  1. train recruiters into what are the type and levels of the programming trade
  2. stop being superior assholes and look for talent and determination where we least expect it
  3. bring people on board and wait on them to catch up
  4. hunt down exceptional full stack generalists
  5. grill down at the whiteboard those who should actually do anything at the whiteboard after we hire them
  6. let people show what they can do, it is really not important what they CAN’T do, that is simply an elitist bullshit. You ask someone: what can you give? they say: THIS, you value that and offer some money. That is how it works. You don’t go to the market and ask the seller: what color do these oranges NOT have?
  7. train teams in the company on how to do interviews
  8. have procedures, not winging it with random questions that other bored programmers make up for fun
  9. measure recruitment success, recruitment conversion rates, recruitment diversity and inclusiveness
  10. be humans and let others be humans back at us

Can we do it?

I hate bacon, kill me.

Lately i keep seeing articles like the one linked here. This idea that we developers like to promote, that its all havoc and mess (like this article itself is) does two things, perfectly well:

  1. keeps people off this industry as a career option
  2. makes everyone else think we’re simply lucky that the first ones want more out of life.

Number one is simply another form of brogramming while number two is a great risk to each generation entering this field to have a really crappy life and a really late retirement.

Its a funny article and i did laugh a lot. At first i thought about translating it but then i realized i’d be only sponsoring a state of fact which i really dislike: greasy bacon. The bacon culture is eating out our craft, and I don’t like it. We seem to somehow be proud of this. To quote someone I look up to, we’re flying a rocket and keep working at the engines and while for teenager adventure spirit this sounds cool, in reality it is not.

Aww, isn’t that cute? BUT IT’S WRONG!!! — Mr. Hollywood http://9gag.com/gag/a9M4A7K

We live in a non critical world. We make project management software, email clients, check in apps, messengers, shops, friend lists etcetera and we can live with all these being flaky, down, unresponsive and what not and also we laugh at the funny “we’re sorry the cat chewed our network plug” PR stunts at the end of a downtime. But what will happen when the same code and the same programmers will make code running the electric grid? Your car? Nuclear power plants? We’re not far from that, you know.

You’ve heard the crap that exploded at healthcare.org and you’ll see even more than that in the next fifty years. So far there is no technological breakthrough that somehow magically takes care of our stupidity, so therefore we need to manage it ourselves. What do we do instead? We make fun of how bad our code is and feel like artists that create snowflakes. Its wrong! We’re artists that create snow! You and I are part of the gigantic team that currently transforms the planet. We are driving home the future. With every new feature you learn and use, with every new tool you open source, with every new product that excels online, we’re building — carving — our way into the future where the Internet will be that huge abyss of everything and we’ll use it to live forever, know everything, cure our diseases in 2 hours and have a lifetime of leisure.

You know its possible don’t you? You may think that your work doesn’t matter, that, like everyone else, a “small cog” in the system is irrelevant. But its wrong! You are a golden cog in the fanciest and most promising system humanity has built in the last one million years! You are paid and catered for as if you were a golden cog right? I mean you must see the difference between you awesome job as a programmer and the people who, for example, do accounting work and go home after ten hours of pushing numbers into tables.

So while you’re being treated like a golden cog you behave — even feel — like a tin one. Why? Why would you consent to knowing a zillion tools and not a single one at expert level? Why when asked to support your choices you always revert to personal subjective preference instead of building up a case for what you stand for? Why don’t you contribute back? ☺ Why do you actually “save” code that you know to be wrong? Why don’t you ask for code reviews? Why don’t you do code reviews? Because you are lazy, you like eating bacon and coding with greasy hands and i hate looking at your keyboard ☺But its cool, isn’t it? It is, until people’s life will depend on it.

In the non critical world we can afford bridges held in place by strings we have no clue about, but if it were a real bridge ran by our web software would you still hack your solutions knowing your children go trough there every day to school?

I believe not. Actually the truth is that you may not be in a critical industry, right? Without the free lunch, leisure like system that being a programmer nowadays means, would you be still be sweating code?

I think we should be mindful when we compare to other lines of work. In general we do easy work, while filled with effort — from carpal to back problems and lower fertility, to the endless hours of mind stress — yet compared to 99% of what’s out there we are faring way better. So stop whining that programming sucks and get better at it. Its your job and it should be your pleasure.

A skill scale for developers

An unruly take on the notion of performance


In building this scale of skill, the units I am considering are as follows:

  • Amount of effort — the quantity of individual time (based on a pondering coefficient) that the person is spending on the test task.
  • Outcome — how much procentually did the person accomplish from the assignment.
  • Cadence — how often are the best effort over outcome results seen in time.
  • Environment —what is the amount of stress that the person needs to handle aside from solving or completing a task.
  • Time — each task is part of some set and each set has some deadline, a slot of time, which is more or less the time required to work on the set because of external factors. can the person fit in the slot?
  • Social — this tests team engagement levels and is related on how much there is a need for the team to support the individual, and how much does the individual support the team.

Here is the definition of the standard ideal* types:

*ideal is like … unicorns, reality is like, you know, … a horse.


Master
The least amount of effort with the maximum of outcome, on a regular basis, under stressful conditions, with results visible none later than the deadline.

Rockstar
The ideal outcome with solely individual effort, on a regular basis, in extreme urgency conditions, with results spot on the deadline.

Expert
The maximum of outcome, within the initially planned effort, on a regular basis, under normal conditions, with most results meeting the deadline.

Proficient
The best outcome, with hard to plan in time variable effort and above average success rates, meeting deadlines.

Senior
The expected results, correlated with team efforts, which often fails under strong pressure, missing deadlines.

Mid level
Work done with results, depending on the sustained team efforts to be on deadline, often missing them and with fault diluted in the organigram above and below.

Junior
Long waiting for some expected results, based on individual effort and usually uncorrelated with any deadline planned.


And here is some ideas on how to implement the above levels in working day to day projects

Axioms

  • You can’t make a team with a master and a rockstar at the enterprise level.
  • Master and rockstar is the dream team for the startup.

Always

  • Prefer proficient to expert if the team is small
  • Prefer junior to mid level if the project is new or interesting.
  • Choose mid level if you have on going maintenance to do.

Remember

  • Real talent jumps from junior to proficient very fast and has only a brief stop at expert level.
  • People from academia become masters late in life, mostly because:
  • People from academia spend a (too) long time in the land of expertise.
  • Rockstars from academia is a rarity mostly because of the peer review system (think of R. P. Feynman from another field as an example)
  • Proficient people will generally mistakenly target an expert level income.

Never, never say never, however:

  • Never assign team leading to rockstars, they can do it but its rarely something they’d enjoy, like writing staff reviews.
  • Never have the expert report to more than one manager, as experts have very carefully planned time and repetition kills their agenda
  • Never involve juniors in more than one project at once, well maybe unless they are interns, in which case you’re doing them a favor
  • Always give blurry, loosely defined tasks to mid-levelers and sharp, clearly defined tasks to proficients.
  • Then again, never say never

What am I supposed to do with this? Well self assess, assess others, read CVs and stories with these glasses on when choosing partners and co-founders etc. Lots of useful situations ☺

Project zombification, the business of the walking dead

office zombies that draw the energy and passion of your team

Here are a number of situations in which the essence of projects is killed. The result transforms projects into real office zombies that consume the energy and passion of, otherwise, talented and creative designers, developers, managers and entrepreneurs.

Zombification of a project occurs when a finite thing, that should have a start and an end, gets transformed into a long, operations-like, daily routine. It will spawn on its own from the proverbial “about one month”, to a year or more with zero results. As a slightly true rule,

when the deadline becomes foggy get ready to fight the zombie in the fog.

The reason for zombification is the infiltration of virus-like bad practices into the approach of the team. These bad practices mutate the, once fun and lively, project into a slow sloth, that nobody enjoys, and which acts like a mythical business sucubus.

Here are some bad practices for whom i required months of isolation therapy afterwards because of zombie interaction.

UX is tricked into UI

Probably the root of all evil. The good ol’ UX waits to be designed and nobody even notices it. Catchy visuals, smooth animations, hours of work poured into pixel perfect client side implementations, but no explanation exists for why does the app have a dashboard, what is the user’s ideal flow, what is the sales funnel, what is the main activity funnel — nothing.

Developers have no idea how to implement their OOP, because no UX means that out of some Photoshop comps they can hardly identify more than isolated database tables. Nobody took the time to make a user story, to define what is the main information the app handles, what is this information’s properties and why are each one of them significant: here come ORM code generators for making so called “models”.

So the user experience is watered down and instead an user interface is produced that servers basically as a glorified mockup of some nice ideas, emanated by whomever initiated the project. This bad practice is so extended that articles upon articles are revealed on a simple google search about how UI is not UX and how the very root of the problem might start with the universal hiring of: UX/UI designer.

For this particular bad practice let me draw a parallel with the advertising industry in which i have several years of direct experience. For the high risk, expensive and closely scrutinized activity of producing a TV, print or radio commercial, the art directors — which would be the equivalent of your UI designer — almost never produce the whole thing on their own. You’d get at least a duo of copywriting and art direction, if not even involve a bunch of other people from the brand manager to the client service executive. Because, you see, apart from the visuals and headlines and catchy USPs, the thing needs to have a story, a flow, a meaning that would highlight the benefit for the consumer. It must show clearly why the consumer should throw their money at you. That’s UX in advertising. You can’t do it with UI only, no matter what you sell.

Flat, 10% rounded corners, single page parallax html5 angular

This is known in the scientific community of web development theorists as the “buzzword syndrome”. Because of some mistaken stakeholders, the project must be built according to the summary of the latest “A list apart” feed combined with the TechCrunch trending subjects and some HN pizzaz.

It doesn’t matter if developers can’t figure out how to cache the assets — they are flat so we’re good. Never mind nobody ran a usability test or that the product manager forgets how to use the product on a daily basis — as long as all the corners are rounded (to match everyone’s Apple display bezels) we’re set free of any problems.

But, while coders and programmers suffer very often from this bad practice of infesting specification with buzzwords — for example “build it with angular and have a node backend for this stateless landing page” — the most hurt are visual designers. Trend conformance, as observed by others too, produces so many bland results and zero creativity that eventually they drop using Photoshop and revert to MS Paint instead to ease the cerebral burden.

Its really one of the most intriguing bad practices since there are countless examples of huge products built on proven grounds. However its easier to build a PR scheme if the app “RoRs”, isn’t it?

IA is fooled into MVC

Probably a mutation of the project zombification virus released into the wild by 37 Signals. Its adoption was so wide that it became practically immune to any forms of cure. You can throw all your UML plans at it, its not gonna have any effect.

This bad practice acts by replacing any kind of prior planning about how the application will be built, with the proven knowledge that it’ll use MVC. The most common implication is that all the tables are models and we’re done with IA. Who needs an information architect to create a coherent data model with proper inheritance, logic foreign keys and clear access to the future object’s hydration? Nobody, and even more, we’ll hire a database consultant only after we’ve built hundreds of tables with code generation tools provided by our generic and well intended framework. Poor database admins, they will be hunted down by the zombie project armored with a never ending stream of impossibly poor queries.

Also, another side effect of this bad practice is the worldwide spread ignorance of the very features platforms offer because, hey, if its MVC, who needs a database view, a stored procedure or a server side data collection daemon … seriously!

Warning! These are the zombie projects that upon a successful attack spawn ignorant professionals which carry on the contamination to other projects too.

Brick-a-brack projects

It’s also called the poor man’s MVP. It has to be done in a week. Nobody dares or cares to count rationally, or just add up, the estimate time that should be poured in. Then, surprisingly, because of good talent, in a week, the project becomes a fair idea to show to close friends, but instead its showcased to VCs as the next yacht producing IPO and from there on the promising little foundation gains monster additions.

People who had projects zombified by this bad practice are surely worn off already by random and semi-random admin panels and wizards, needed impossible screen scraping, countless strikingly similar features implemented as separate application modules, or, the worst, 180 degree turnarounds from last week’s idea by an improvement suggested in some video call, a small “improvement” that is requiring whole codebase refactoring.

These are the zombie projects that tend to have the most mana of them all. They appear to never have a solution, an end, a vague idea of when the absolution will descend upon the poor project team members, that are throwing their lives away fighting with it. Even if you somehow escape these zombie projects’ deadly stalk, they’ll come back later on to haunt you and wake you up at 2 AM with servers gone MIA and customers loosing their hard worked content, just because of some wrong flag being set in some table that nobody thought was still in use.

PM is bamboozled into daily stand-ups

This bad practice is a mutation of an otherwise friendly foe called “Agile management and its manifesto”. What was thought initially to be the cure for project zombification, later distilled into SCRUM practices for even more efficiency, a project vaccine really, was apparently defeated by superior zombie cure resistance.

The immediate effect is having no idea what phase the project is in, even after months of sprints. People get into automaton mode and relay their previous day’s wrote lines or icons produced then quietly wait for the others to do the ritual, all just to advance the day before lunch break.

The late observed effect is the crippling to death of the project’s critical path, its spine some say. Daily standup in (and weekly sprint out) there is an endless stream of stories which get backlogged because nobody took the time to think about their dependencies, their natural order or the implications and correlations with other stories. Epic stories are non existent: you have to estimate, no questions asked, and you shouldn’t care since you’ll re-estimate next week anyway.

In fact, this zombie project is the brainless type, with no actual project manager in charge.

Everything is fine until its not

Also called the enthusiasm backed bad practice. Happens a lot on fresh seeded ideas, angel backed revolutionary products or even lower profile marketing websites or intranet applications. The general symptom is that there are no problems whatsoever as so many weeks go by. Then, suddenly, people are fired, management changed, direction switched, code trashed, zombie project apocalypse starts.

Most hurt by this are, as always, the employees — the lower on the chain or outer on the circle, the worse they get hit. Plenty of folks are churning away happily at their three hour a day tasks that they’re assigned, until the project has a relapse into zombie mode and they are slapped with a slew of bad evaluations and logic defeating managerial reviews. Sprint after sprint is being completed, and with the required party thrown too, just to suddenly be attacked by the project that got switched into a fixed-deadline-waterfall soaking the team. Nobody seems to count the increased velocity, the outstanding quality code produced, the superb UX resulted in applying clear fear free principles in managing a cross functional team, just because suddenly, out of the blue, Steve Jobs appears in ghost form in the meeting room screaming “Rrreaaal aaartiiistsss shiiiipp!!!”. Be advised, these words are a magic spell to turn a well intended agile project into a powerful level ten zombie, that takes a dozen morales a day into oblivion with each strike.

This last one is such a wide spread bad practice that you cannot even hope to escape. It manifests in various unexpected forms: “it doesn’t matter that its great, if it won’t make any money”, “how do our core 10 users, which we know by name, benefit this”, “we must perfectly match our estimated sales plan” — all having one simple description: large truisms that fail to be useful in the context in which they get used.

The projects affected by this mutation converts to a guilt generating, and stress feeding, personal life deprivation for all involved. These are the zombie projects that leak outside the office into the home and drive significant others mad or distant (indeed! a weird and scientifically unexplained result).


Truly, I am sure you’ve seen plenty more other mutations of the project zombification virus in the wild. I hope, and dare to dream, to the day when the advanced minds of think tanks and labs found in the academic world will take this huge waste of human potential seriously — and, maybe, with a bit of investment and trial and error, a true cure for the virus will show up in the form of some kind of mutual agreement upon best practices, task durations, the universal biases people have and the acceptance of these biases and so on; i hope to get to see this wild mix of ingredients making a business vaccine — and then getting amused by the crowd of truthers that will refuse it because it gives way too fast stock options monetization to the initial hires.


Thank you for getting informed and take good measures to stay business healthy. If you care for others (shameless guilt exploitation) click the recommend button below (there was the call to action). Cheerios, Andy.