I expected a fast car. I didn’t expect one with ten compressed-air propulsion nozzles using SpaceX-derived technology, plus an underbody suction system capable, according to Elon Musk, of pulling up to 2 G. During the demo, Tesla announced zero to 60 miles per hour, nearly 97 km/h, in 0.81 seconds. It did not disclose the measurement protocol.

This is the future I wanted to see.

The entire demonstration is in Tesla’s official livestream. Road & Track measured and described the maneuvers, while TechCrunch detailed the three versions: Performance with active aerodynamics and suction, Thrust with rear thrusters, and Rocket with a ten-nozzle propulsion system and a single seat.

Of course, we watched a prototype in a controlled demonstration. Tesla expects production to begin in 2028, and the Rocket version is not approved for public-road use. Still, an actual car left the ground, rotated, and landed. I watched it live from my office. It was spectacular.

While Musk was landing rockets and making cars fly, I was doing something far smaller and more mundane: fiddling with my websites.

Six sites in about a day

Before the Tesla event, I spent the entire day redesigning six sites:

• Akita’s AI Lair, now matching the look of my new book, Competent Enough;
• ai-memory;
• ai-jail;
• The M.Akita Chronicles newsletter;
• the newsletter archive;
• and this blog, AkitaOnRails.com.

They all started with variations of that default theme Claude makes. Dark background, purple or blue gradient, huge sans-serif type, rounded cards, a glow behind something. It works. It has also become so common that you can spot a “site made by Claude” before reading the title.

I had already tried asking Claude for different designs. It changed the color, moved the cards around, and delivered the same visual grammar. I posted some screens and the result of the change on Twitter. I’m no web designer, and for a while I accepted “it works.” Yesterday I got tired of it.

Someone suggested Stitch by Google. It’s an experimental Google Labs tool that turns instructions and images into editable interfaces and front-end code. The first version launched in 2025 on top of Gemini; the current version has become a design canvas with an agent, prototypes, and export to a DESIGN.md that other agents can follow.

I signed up, got the API token, and went to work. Stitch generated visual directions. Claude Code and Codex brought those directions into the real repositories, adapted the components, fixed responsiveness, replaced images, adjusted SEO, tested, and deployed. When one quota ran out, I continued with the other.

The six sites come from five repositories. Looking at them side by side made one thing clear: Stitch responds much better when it receives a concrete metaphor, the audience, and what the product needs to communicate. ai-memory became a memory archive. ai-jail became a cinematic prison. AI Lair adopted a 1950s and 1960s world’s fair, drawn from my book cover. The newsletter became a late-night broadcast, and this blog became an editorial archive. Five different identities instead of five variations of Claude’s same gradient.

The pretty prototype is the easy part. The job only ends when the visual language reaches internal pages, the article, the book reader, email, legal pages, error states, and mobile. That’s what the agents did inside the repositories. On ai-memory, for example, verification covered 102 pages in six languages, light and dark themes, desktop and mobile. On The M.Akita Chronicles, the same design had to work across signup, archive, newsletter detail, podcast, and the email template. A Stitch mockup solves none of that by itself.

Each site went through several rounds of prototypes. Some looked awful. Others had one good idea surrounded by bad decisions. I told the agents to throw them away, preserve one part, mix it with another attempt, and start over. Code is cheap now, so there is no reason to fall in love with the first version.

The result won’t win a design award. A professional designer would still find hundreds of things to improve. I know I could take it further by spending a few more days. It looks much better than it did, though, and for now it is competent enough.

Six existing sites redesigned, responsive, with SEO, image generation and replacement, HTML, CSS, and JavaScript adjustments, testing, and production deployment. One person. About a day. A year ago, that package would have taken weeks or months.

Keep the scale in perspective: these are small sites, mostly landing pages and content pages. Nobody is rebuilding Amazon.com’s entire collection of pages and systems in a day. The experiment shows how much repetitive work has already moved out of the way within a scope that one experienced person can understand and review. Large projects remain large, full of private rules, old integrations, strange states, and decisions that do not fit in a prompt.

Even the first proofreading pass can be automated

As part of the same process, I had agents review the sites as different readers. This wasn’t grammar correction. I wanted to know what someone would understand in the first few seconds, where they would get lost, which promise would sound suspicious, and whether they could complete a task without already knowing the product.

On ai-jail, I used two isolated sessions. One played a skeptical engineer who approves every prompt and had never heard of the project. The other was a non-engineer managing eight developers, trying to decide whether to approve the tool for the company. On ai-memory, I used three: an engineer learning AI tools, a manager evaluating a pilot, and a parent with no agent experience who worried about AGI and jobs. Each one read the site without seeing the others’ reports.

Anyone can do the same thing. Run the application locally or open a preview deployment, start fresh sessions, and give each agent a concrete task. A basic prompt can look like this:

Open this site on desktop and mobile: [URL].

You are [persona], know [context], and have never seen this product.
Your goal is [specific decision or task].

Navigate as this person. Do not read code or internal documentation first.
Record:
- what you understood in the first ten seconds;
- what you think the product does and who it is for;
- where you did not know the next step;
- contradictory, absolute, or hard-to-believe promises;
- terms the site uses before explaining them;
- reading, keyboard, contrast, touch, and responsiveness problems;
- what would stop you from trying, buying, or approving it.

For every finding, show the page and visible evidence.
Separate factual bugs, usability problems, and subjective preferences.
Do not propose a broad redesign. Suggest the smallest change that solves the problem.

I prefer three independent sessions over an agent roundtable. Once one reads another’s report, it starts agreeing by inertia. A separate session can then consolidate repeated points, discard matters of taste, and check every claim against the code and product documentation. A review can flag a sentence as wrong; it has no authority to invent the right one.

The most useful results tend to fall into four groups: positioning, information order, path to the first action, and trust. Traditional automated tests still handle broken links, contrast, accessibility, overflow, and error states. The persona tells you that a technically accessible button appeared five screens below where the person needed it.

During the ai-jail proofreading, both profiles agreed that the site took too long to show a concrete risk and started speaking like engineering documentation too early. The threat of a poisoned page moved directly below the hero. New sections explained “What changes on day one” and “For the person who must approve this,” including operating cost, limitations, and the keys a company actually exposes. The review also caught a technically incorrect claim repeated across several pages: the network does not stay entirely off by default. The agent’s own API host and, on Linux, registries remain accessible. This kind of reading catches documentation bugs too.

The ai-memory report found permissions described in contradictory ways, privacy promises that were too absolute, and the basic explanation buried under advanced features. During the second round, the profiles noticed that remote-access instructions told users to use HTTP before requiring TLS, that an unauthenticated curl promised the wrong response, and that important choices appeared far too late on mobile. The collection guide moved from about 4,364 pixels from the top to 1,617; the individual and team paths moved from 5,300 to 2,489. That’s an objective improvement born from simulated reading.

In the AI Lair redesign, the new-reader review reorganized the entry path. A later revision made it explicit that my setup with multiple agents and two monitors is a mature configuration, not a requirement for starting. One person, one project, and one agent are enough. It also produced a pilot plan for managers: a reversible task, non-sensitive data, an acceptance criterion, deadline, budget, and measurement. The next audit found invalid ARIA and an animation that hid the opening copy from assistive technologies; the fix took axe-core from four serious violations to zero.

Simulated personas still fall far short of human feedback. They carry the models’ same biases, may agree with the prompt, never feel the irritation of someone who lost twenty minutes, and never take the risk of entering their own credit card. The reports serve as hypotheses. A real user will always find the case that I, the agent, and the test suite failed to imagine.

Before the first user exists, however, the alternative is usually no review at all. Two or three independent readings already catch contradictory promises, unexplained jargon, buried information, and a flow that only makes sense to its author. These readings cost little and make the product less stupid before it reaches actual people.

HTML was never programming

For years, I watched people perform some remarkable mental gymnastics to argue that “HTML is a programming language” and therefore anyone who writes HTML is a programmer.

HTML is markup: it describes a document’s structure. CSS describes presentation. That has value, requires knowledge, and can become terribly complex. Accidental complexity does not turn markup into programming.

There is no shame in that. I started building sites in the 1990s. I received a Photoshop layout and turned it into HTML. I sliced images, built tables, adjusted pixels, opened the result in multiple browsers, went back, and tried again. It was honest work and paid my bills.

It was also basically mechanical work: copy, paste, adjust, look, repeat. Exactly the category computers should automate.

Today I still chose the visual direction, rejected bad proposals, decided what each site needed to communicate, and recognized when the result was good enough. The agents handled the grunt work. This should have happened years ago.

The bubble delayed automation

For much of the 2010s, US interest rates stayed near zero. Cheap money flooded funds, startups, and large companies. Hiring more people was easy, and the market absorbed any amount of manual labor disguised as engineering.

Low rates explain only part of tech’s expansion. A field breaking hiring records has little incentive to eliminate its own repetitive work. If you can put fifty more people to work assembling screens, you put fifty more people to work assembling screens.

Anyone who attended my talks at tech events in the 2010s may remember Constraint == Innovation. Yes, the original title used two equal signs. I gave that talk at DevConf 2019, the 83 slides are on my SlideShare, and I had already written the same argument in 2013 in “Constraints are liberating: less is more”.

It’s the old maxim: necessity is the mother of invention. Constraints force choices. Choices force priorities. When the conventional path cannot fit the money, deadline, or available capacity, someone has to find another path. That’s where real innovation often comes from.

Money funds expensive research, buys equipment, and gives people time to experiment. Excess money without pressure for results does something else: it hides inefficiency with brute force. There is no need to automate, simplify, or discover a better solution while you can keep hiring and growing the spreadsheet. Too much abundance turns a technical problem into an operating expense and postpones the difficult decision.

I repeated this warning at the beginning of 2026: the programming bubble managed to replace efficiency with volume. Constraints returned when cheap money ended. Coincidentally, agents arrived at the same time and gave companies a practical way to automate the mechanical work they had spent a decade scaling through hiring.

That’s how we spent a decade recreating the same admin dashboard and calling it innovation. Every week brought the next front-end savior: React, Angular, Vue, Svelte, another bundler, another framework on top of the framework. They are useful tools in the right context, but none addressed the obvious question: why is a human still hand-writing the thousandth variation of the same form?

The hiring bubble burst in 2022 and ended the party. At the end of that year, ChatGPT brought language models to the public. GPT-2, just to keep the chronology straight, had come out in 2019. Four years after ChatGPT, agentic programming became a normal work tool.

Any task that consists of copying a pattern, adapting an example, running it, looking at the error, and trying again is already within these agents’ reach. Front-end is the most visible target because it accumulated an absurd amount of this work. The rest of programming has no mystical shield. Plenty of back-end work is CRUD, glue between APIs, and repetitive configuration. That will be automated too.

Fine by me. Programming was never about typing code. Programming is making a computer do something useful.

VS Code is the new punch card

I wrote about exactly this in April in “VS Code Is the New Punch Card”.

For decades, the interface between intention and computer kept changing. First you connected wires and switches. Then you punched cards. Then you wrote Assembly, C, high-level languages, frameworks, and configuration. Each generation looked at the previous one and automated another layer of manual work.

No sane person would argue today that operating a card punch was the essence of computer science. It was the available interface. Typing every tag and CSS rule into VS Code was also the available interface.

Now I describe the intention, show references, evaluate the result, and tell the agent to fix it. I still need to understand browsers, networks, caching, accessibility, semantics, responsiveness, and SEO. Without the fundamentals, I couldn’t tell whether the agent delivered a solution or a pretty time bomb. The keyboard lost importance; judgment gained it.

Today, every Tier A model I test, from Claude to Kimi, can reliably execute the mechanical front-end work that appeared in these six projects. I can say without hesitation that any front-end task that merely turns an already-made decision into code is automatable. They needed direction to create the six designs. None required me to hand-write the flexbox, breakpoint, or component I had already explained.

That covers an enormous share of the work while leaving the most valuable part. Someone still has to know the framework’s tradeoffs, understand the browser, choose the architecture, notice when a library is being forced against its design, and find out why an apparently correct solution breaks under a particular combination of device, language, state, and real data. The agent writes the code; an experienced professional provides direction, limits the damage, and owns the result.

Front-end still exists. The excess mechanical work and the people hired only to follow a finished recipe lose value. A great front-end professional can direct agents and deliver far more than they could alone. A mediocre professional who spent years mistaking component typing for engineering will compete for fewer openings. The market gets smaller and more selective, with its best professionals producing more. The goal remains what it always was: get close to the top, where judgment and experience still make a difference.

And it doesn’t stop at the browser. Pick the framework: Android with Flutter or Kotlin, iOS with Swift and SwiftUI, desktop with Rust/Tauri, Flutter, C#, or Electron. Modern agents generally know the components, build tools, tests, and peculiarities of these platforms. They still need direction, feedback, and verification, just as they do on the web front-end. The mechanical part is already automatable.

I tested this in my own small open-source projects. FrankYomik has a Flutter client for Android and Linux, plus the server and extension. Frank Sherlock is a Rust/Tauri desktop app that produces an AppImage for Linux, a DMG for macOS, and a .exe installer for Windows. I also built Frank Karaoke in Flutter for Android and FRANK MANGA+ in Rust/Tauri for desktop. There are several others on my GitHub.

None came out perfect from the first prompt. Flutter and Tauri gave me trouble, especially on the early projects. Reliable means the agent can move forward, receive a correction, create tests, fix what broke, and reach a working application without making me take over the manual typing. After testing web, Android, and desktop across different stacks, I’m very satisfied with the result. The pattern repeats: mechanical work became agent work.

At two in the morning, I had agents making the final adjustments to this blog without losing pace. That’s what I need.

When the web still didn’t know what it was

At the peak of the dot-com bubble, career designers were creating websites. The web had not yet decided how a page should work, so there was real room to experiment. It was often ugly and almost always heavy, but actual creation was happening.

The iPhone opened another window in 2007. Suddenly everything had to fit on a small screen, respond to touch, and work without a mouse. Years of experimentation followed before the market settled on a reasonably stable grammar for navigation, gestures, forms, and content.

Today nobody needs to rediscover a menu, a list, a checkout, or an article page. The patterns are documented, millions of examples are public, and models have seen more interfaces than any person could study in a lifetime.

The most valuable work remains: understanding the product, the person who will use it, the constraints, and what deserves to appear first. Converting a finished decision into hundreds of predictable lines has become a perfect candidate for automation.

Jobs disappear. Others appear

The world has never stopped to preserve a job function.

Punch-card operators entered data and programs on paper cards. Telephone operators physically connected calls. Typists kept offices running. Linotype operators cast lines of hot metal to print newspapers. Technology reduced or eliminated these occupations at scale. The Bureau of Labor Statistics’ current list of fastest-declining occupations still includes data entry keyers, typists, and telephone operators. Nobody proposes bringing them back to protect jobs.

At the same time, jobs appeared that a person in 1926 could not even name: mobile developer, SRE, experience designer, Internet video creator, cloud specialist, machine learning engineer. The web itself killed old work and opened an entire industry.

The real story is messier than the caricature. The ILO shows that technology tends to automate tasks without necessarily eliminating entire occupations. Some functions shrink, others change, and new jobs appear. That statistical consolation does nothing for the person who became obsolete today. The individual has to react before the economic average reacts for them.

Compare 2026 with 1926, three years before the crash of 1929. It looks like another planet, even though a century is very little on history’s scale. No contract guarantees that your current function will survive the next ten years, much less the next forty.

How does a junior gain experience now?

It will get harder. The old ladder began with someone paying a beginner to assemble simple screens, fix CSS, and copy components. An agent does much of that faster and cheaper. No company has an obligation to preserve inefficient work as a training program.

Beginners will have to build their own ladder with real projects and problems they are responsible for. That includes reading the code the agent generated, breaking and repairing it, studying documentation and source code, writing tests, and contributing to open projects. An agent gives any student access to an amount of practice that once required a team. Anyone who uses that access only to generate code they do not understand will remain a junior for a long time.

The market will reward people who make that extra effort. It always has. When someone asks how a junior can gain experience without the easy tasks, the hidden question is often different: “how do I get a better salary without doing the hard work of getting good?” The easy position, with rising pay and little pressure, was a distortion of the bubble. Adapting includes accepting that entry has become more competitive.

My career never stayed in one place

I started with multimedia and static websites. Then I worked in a digital agency, enterprise consulting, SAP integration, startups, video, education, and now AI. In my Akitando episode about SAP, I tell part of that phase when I had to learn a world completely different from what I had done before.

I lived through the dot-com crash, the 2008 crisis, and the end of the zero-rate bubble. I survived because I never treated my current function as a permanent identity. I kept studying, gaining experience, and changing direction.

A productive career should not consist of repeating the same mechanical task for decades. If your value depends on the market continuing to pay someone to push tags and pixels by hand, the problem did not begin with AI. The problem was betting that the present would last forever.

Many people understand “being prepared” as studying the bare minimum required for today’s open position. That’s the fastest recipe for becoming obsolete. Do the short-term work, but study beyond it. Learn the things that seem useless today. Fundamentals, operating systems, networks, databases, business, economics, history. You don’t know which combination will save your career five years from now.

I spent years talking about this on Akitando. Revisit the I Warned You and Which course should I take? playlists. If you have to start with one video, start with the Definitive Guide to Learning How to Learn. No course can save someone who still outsources their own learning.

The world has no shortage of opportunity. Most people feel they never get one because they are always unprepared when it appears. Once the opportunity lands in front of you, it is too late to start preparing.

So I won’t mourn the fact that this package of six small sites, which used to take weeks or months, fit into about a day. I’m happy as hell. I gained time to think about what to build, experiment more, and throw away bad versions without wasting weeks of my life.

Today I watched a car spin in midair and land. In about a day, I put six sites with new designs into production without writing most of the HTML and CSS. The future I wanted did not arrive perfect, cheap, or evenly distributed. It arrived far enough for me to work with it.

Accept what ended. Study what comes next. Be ready before the next opportunity appears.

“AIs will NEVER replace ANY programmer”

And that’s wrong. Watch the video with the explanation (or look for the transcript). But in short, what I said was:

“AIs will never replace programmers LIKE ME — I will never be replaced”

Another thing I stated and keep stating is:

“AGIs are not possible in the current architecture: it’s not going to happen. A new discovery needs to show up — one we obviously don’t know yet — to break past the current barrier, which is insurmountable.

And that’s where I derived this line from:

“Your excitement about AI is inversely proportional to your knowledge about AI” — and it still holds just as well.

The Programming Bubble Already Popped

My channel started in 2018 and ran until early 2024, with a single purpose:

Helping to prepare real programmers to survive the imminent popping of the bubble (which started around 2014).

I have a whole playlist titled I TOLD YOU SO.

In short, in recent years, “programming” became the “profession of the future”, and it seemed easy. It got obvious when all you saw was ads for every kind of course and bootcamp, with promises like: “become a programmer in 2 months, earn a Google salary, and you barely even have to work.”

I called this kind of programmer the “instant noodle chef”. Just because you know how to boil water and make instant noodles doesn’t make you a chef. It should be obvious, but that’s how programming was sold. None of those courses produced any “programmer”, let alone a “software engineer”.

But “software engineer” is not real engineering. There’s no CREA, CRM, OAB, or any equivalent body that certifies anyone as a “software engineer”. It’s a made-up title anyone can slap on their LinkedIn.

The Black Swan of the Pandemic was something I didn’t predict, but it only helped inflate the final phase of the bubble even further, which popped at the end of 2022 when mass layoffs began across every big tech. And that was BEFORE the advent of LLMs for programming. Coincidentally, ChatGPT showed up around the same time in 2022, but it was not the cause; it was just the last nail in the coffin. The popping of that bubble and the layoffs would have happened anyway.

That’s why my channel must be the only one that, to this day, offers the content someone who actually wants to be a programmer needs. Imagine the other channels that only pushed the narrative that becoming a programmer was easy — they aged VERY badly.

So yes, I agree with Anthropic’s CEO: those “software engineers” will become completely obsolete. Nobody becomes an “engineer” in a 1-month bootcamp. That was bullshit and you had to be really dumb to believe it. Notice how all those snake-oil sellers VANISHED. Where are they?

Don’t know where to start on my channel? Two suggestions:

• Playlist “What courses should I take?”
• Playlist “Career”

The AI “Ceiling”

I finished recording videos for my channel exactly when the AI wave started. I considered that everything I wanted to say had already been said and it all remains available on the channel. My goal was accomplished.

During 2024 and 2025 I took part in podcasts like Flow and Inteligência Ltda talking a lot about AIs and things like quantum computing (and how it too is just hype that won’t amount to anything practical in our day-to-day).

The main point: since the transformers paper Attention is all you need, no other “breakthrough” has appeared that surpasses that milestone. Everything we have today, from OpenAI to Anthropic, and from open sources like DeepSeek, Qwen3, GLM, MiniMax, etc., is based on exactly the same foundation, the same “architecture”.

And I theorized — correctly — that the evolution of this architecture would follow an S-curve:

GPT-1 to 2 was a quantum leap. GPT-2 to 3 was a gigantic leap. GPT-3 to 4 was excellent, but, notably, not in the same proportion. GPT-4 to 5, most regular people barely noticed the difference.

Of course, nobody stood still; every computer scientist, mathematician, engineer kept doing what we always do: optimizing. Better training methods showed up, the idea of “reasoning”, the idea of agents working together (one giving feedback to another), new forms of alignment and instruction. But none of that changes the foundational architecture.

The problem: training each new generation of LLMs gets considerably more expensive (in hardware and, mainly, in energy consumption) to produce a version that isn’t much better than the previous one. That’s the ceiling of the curve. And I reaffirm: until a NEW ARCHITECTURE appears, we’ll only get closer and closer to that ceiling, without crossing it, while spending absurd levels of more memory and more energy.

That’s why there’s an energy shortage: with the increase in usage demand (inference), they have to split between spending energy on training new versions and serving demand. They can’t do both.

Worse, that’s why RAM prices exploded and your PC will get much more expensive too. There are no more resources to train models so big that, proportionally, deliver less and less result (the definition of “diminishing returns”). It’s the fate of every innovation: hitting the ceiling of the S-curve until another one comes along to replace it.

The focus now is on using the versions we already have better. In the programming case, you get GPT Codex or Claude Code, which are strategies for using agents, MCPs, skills, and other tools and forms of orchestration to squeeze the maximum out of what we already have today.

LLM Strategies

Everyone already knows it’s impossible to just write a prompt and have any LLM spit out a perfect system in the end. It will come out very bad; it stays that way and will stay that way in this architecture.

Every LLM has a context (memory) limit. It’s impossible to load the entire source code of a giant ERP like Totvs’s or SAP’s. It doesn’t fit, and even if it did, it wouldn’t be possible to give “attention” to all of it. There are limits: the more memory you load, the worse inference gets; the result gets worse. Like everything in software, it’s a “trade-off”.

Instead, the best thing is to create scripts that walk through your code and extract specific chunks on each run. If you’re working on the shopping cart, you don’t need to load the code that handles the store’s landing page, for example. It’s similar to what a human programmer would do: divide and conquer (as Napoleon would say).

Every LLM specialized in code, like Codex or Opus, was trained to do “tool calling”, which is sending a request to the “chat” so it can fetch information (such as code) and load snippets into the context. For that, it has it run tools like “rg” ripgrep (in Codex’s case) or “grep” (in OpenCode’s case).

If, by chance, the model wasn’t trained on information that only recently came out on the Web, it can do “agentic fetch”, which is executing commands like “curl” to literally go to Google, Stack Overflow, etc., and pull web pages in to use as part of the context (the trade-off is that this will use up the limited context space).

When the context is about to run out (the 200k token range, in Claude’s case, or 1 million, in Gemini’s case), the “chat” that orchestrates (Claude Code, OpenCode, etc.) triggers a summary of the current context, to “compact” the understanding and restart with a new context based on that summary.

To make sure the generated code “works”, tool calling asks it to run local tools like linters, compilers, or LSPs (like an IDE, like VSCode, would). This produces feedback (and burns more context). If it errors, the “chat” can automatically ask it to redo the work, taking this new information into account.

Also, to go “faster”, the “chat” can fire off multiple agents in parallel. Each agent is a new context — and none of this is free, remember: tokens per second. So, it could send one agent to comb through all the code relevant to the database and, at the end, produce a summary. Another agent combs through all the payment code and, at the end, generates a summary. Another agent combs through the cart front-end code and produces a summary. Then the “chat” takes those summaries and goes back to the previous context to execute some task.

What I call “chat” is just to make it easier to visualize. Think of the simple chat interface everyone uses day to day, but with additional features. That’s what a Codex or a Claude Code does. There’s no secret, every tool like this, as well as open source ones like OpenCode or Crush, do the same thing: they set up a “Harness”:

• They start with a system prompt detailing exactly how they want the LLM to respond. This GitHub has several examples of these prompts the tool sends without you knowing.
• LLMs are trained with tool calling and the tool knows how to respond to those calls (executing bash, curl, ripgrep, sed, diff, git, etc.)
• The tool is capable of running multiple agents in parallel (think multiple “chats” in parallel)
• The tool asks the LLM to produce a “plan” first and enumerate tasks. Then it can orchestrate the sequential execution of those tasks, each in a different agent, for example.
• The tool is capable of managing context limits and knowing when to trigger a summary, and how to start a new context and continue executing the remaining tasks
• The tool is responsible for creating a container and preventing badly formed commands from affecting your system (this is optional; not all of them do it or care by default. Watch out!)

I’ve documented this in several posts on this blog:

• LLM Hello World: building your own AI chat that runs locally
• Rant — Will LLMs evolve forever? Demystifying LLMs in programming
• When Don’t LLMs Work for Programming? A more realistic use case.
• AI Agents: Locking Down Your System
• AI Agents: Comparing the main 2026 LLMs on the Zig Challenge
• AI Agents: Installing LSPs for Crush
• AI Agents: Which one is best? OpenCode, Crush, Claude Code, GPT Codex, Copilot, Cursor, Windsurf, Antigravity?
• Vibe Code: I built a little app 100% with GLM 4.7 (TV Clipboard)
• Vibe Code: Which LLM is the BEST?? Let’s talk for REAL
• Vibe Code: I built a Markdown Editor from scratch with Claude Code (FrankMD) PART 1
• Vibe Code: I built a Markdown Editor from scratch with Claude Code (FrankMD) PART 2

The End of Stack Overflow

Back in the GPT-3 and GPT-4 days, I was already writing code using LLMs and it worked well. But they still had lots of annoyances. Hallucinations were very frequent. There was a lot of “agentic loop” (when the LLM “thinks” it already fixed something, but it didn’t, and it stays in a loop, not knowing what to do). Attention to context was easily lost (it improved a lot with Flash attention). Basically, several “rougher” issues have been ironed out to the point that they don’t show up as often. It’s not “solved”; it still happens, but it keeps getting better.

The more training data and alignment improved, the more those problems disappeared. The problem is we’ve already reached the point where the training data in the world has run out. Everything that could be used has already been used. It’s not just the lack of energy and hardware. The information to train on is gone.

The solution was to massage existing data to squeeze the maximum possible out of it and add lots of synthetic data (generated by the AI itself). Again, this already hits a “diminishing returns” ceiling.

On top of that, several sites used to extract LLM training data are falling into disuse. The most notable example is the venerable Stack Overflow. Look at how its traffic has dropped.

Some clueless people might just think: “ah, it’s fine, people started asking dumb questions to LLMs instead, no more piles of people posting basic questions in forums.”

It’s true, it seems like progress. But even a “dumb question” is relevant training data. If the LLM “sees” that certain topics have higher probability, when it gets the same question, it “tends” to give the most popular answer. If this data disappears, so does the relevance of lots of new topics. Now, each LLM will depend on using the questions asked in its own chat as new training data, except OpenAI will only have questions asked to it, and it won’t know which are the most popular questions asked in Claude, which shrinks the sources of relevant information more and more.

What every platform must be doing now is collecting every question you ask it, every answer the LLM produced, every bit of feedback you or your tools give on whether it was a success or an error, and stacking it up to train the next version, GPT-6 or Sonnet-5. Let’s see how much you can evolve with just that — remembering that “volume” of information doesn’t equal “quality” for training. That’s still the Achilles heel.

The point is: at least temporarily, most of the relevant data on the Web has run out, and we’re producing less than before.

Constraint == Innovation

Yes, I also believe an entire category, which called itself “software engineer”, is going to stop existing because of AIs.

That weird “specialization” of “front-end who doesn’t touch any back-end” or “back-end who doesn’t touch any infra” will no longer exist. Front-end, in particular, is the easiest to replace, because it was a huge volume of low-value-added code with lots of duplication. It wasn’t hard to automate, but nobody wanted to: it was “cooler” to keep inventing new frameworks every week that do the same thing in slightly different ways. That circus is finally over.

I lectured for years on Constraint == Innovation and how innovation doesn’t happen when you have money to burn, which is what happened in the last Programming Bubble: why automate things, be efficient, if there’s money to spare? Just hire more and more people to do simpler and simpler grunt work.

In the Internet Bubble, there was so much money to burn that a “website cataloguer” profession existed: people who spent all day manually typing in every new site that appeared on the newly launched Web. It took years for an Altavista and then a Google to show up and figure out how to automate this. Back then, there were no “web admins” to publish new products in an e-commerce site: someone edited the HTML of Submarino.com’s homepage every day, with new deals. All high-volume, low-value-added work. We automated all of that, and now, with LLMs, we’ve just gone one step further.

Even before LLMs, it made no sense to need people exclusively to churn out disposable HTML/CSS all day. The slightly more automatic tools, like a SquareSpace.com of the world, weren’t all that good.

The thing is: something simple, like a “Web Admin” to edit content without needing to know HTML, didn’t exist in the 90s. Someone had to build the first versions of that kind of software so we could understand what works and what doesn’t. Anyone from the 90s will remember expensive commercial software like the famous Vignette Story Server. Today, any open source Wordpress does the same thing better.

Nobody remembers software and companies that no longer exist. Especially young people think the world showed up with the Web ready-made, with social networks ready-made and e-commerce platforms ready-made. The feeling must be that, in Ancient Egypt, people already shopped on Amazon, ordered delivery on iFood, and everyone chatted on WhatsApp. I made a video called The Dimension of Time, My Time Machine and My First Five Years to try to give some perspective on this.

The point is: everything LLMs know how to do either already exists or already existed.

They’re not capable of inventing whatever it is, be it the “Vignette of the 2030s” or the “Instagram of the 2030s”. And I don’t mean that in the sense of the “next content manager” or “next social network”. I mean in the sense that “social network” was a term that didn’t exist in the 2000s and “content manager” didn’t exist in the 80s, for example. What’s the new category that will show up in the 2030s?

I don’t know; if I did, I’d obviously be building it to launch and become a billionaire. Nobody knows, much less LLMs. They can derive a lot of things from training, but what’s not in the model’s probabilities won’t “spontaneously” appear. That’s not how AIs work.

We can stay forever just redoing everything that’s already been done the same way it exists today. But not much more than that. But the whole point of my talks was exactly that innovations are not born from just having tons of money and tons of brute force.

Programmers in the LLM Era

The conclusion is very simple: programmers like me will always exist. What always stops existing are professions that only have volume but low added value. That’s the concept.

As I said in my videos, during my career I’ve already survived the end of the microcomputer bubble in the early to mid 90s, the internet bubble from the mid 90s to the early 2000s, the 2001-2008 programming recession, the financial housing bubble that popped in 2008 but gave birth to the programming bubble, especially from 2014 to 2022, and now the AI bubble.

Don’t fool yourself: it’s always like this, and this is nothing more than another episode.

Who’s the programmer that survives all these bubbles? This one:

The ceiling of LLMs is already here and what they’re delivering now isn’t going to change much: the process is going to be the same. It’ll get a bit faster. It’ll generate a few less errors and small tweaks like that. But the process will keep being the same until some new architecture or some new discovery we don’t know about yet shows up.

No AI-generated code will be automatically perfect to be put into production without any kind of review or human intervention. — Anyone who thinks otherwise either has never tested an LLM in practice or has never worked on real projects.

As I said on Flow, this is the SECOND AI Bubble. The first was in the 60s because of the inventor of neural networks, Frank Rosenblatt. Just like Sam Altman or Dario Amodei, he also hyped neural networks and computers that were going to get much smarter than human beings “very soon”, and every newspaper at the time wrote about it. The promises died as promises and that generated the “AI Winter” in the 70s, where tons of investment was made, the result was not proportional, and AI research stagnated for the following decades, crawling at a turtle’s pace.

That only really started to change with the advent and popularization of the Web, the rise of social networks, the emergence of Big Data, and now, with huge volumes of data to kick off a new era of research on neural networks, with a lot more training material. And now with the existence of GPUs to accelerate processing. That’s when AlexNet showed up, from Geoffrey Hinton, Yann LeCun, and Ilya Sutskever, the “breakthrough” of convolutional neural networks (CNNs) and parallel processing via GPUs.

Without that, we wouldn’t have moved on to transformers, diffusers, and things like Nano Banana and Sora. This is a type of area where LLMs won’t contribute: cutting-edge research and new discoveries. In that field, we’ll still need computer scientists, mathematicians, theoretical physicists, etc. If you have a calling for research, it’ll still be a fertile area for many years. The bar only went up, which is a good thing.

About the Claude that managed to build a C compiler:

A C compiler is the easiest to build; it’s literally college material, because C is one of the “simplest” languages (it started as Assembly macros).

As Anthropic’s own article — which nobody read, of course — says, they used GCC for comparison.

Of course, GCC exists; it’s the main compiler used to compile the Linux kernel. If you copy GCC, you’ll arrive at another GCC, no matter what other language you write it in — that’s not the hard part, because every language can do everything another language can (they’re all Turing Complete: it can be slower, it can be less safe, it can be more work, but I can write a C compiler in Visual Basic if I want, that’s not impressive).

No LLM has replaced Linus Torvalds, nor Richard Stallman, nor any of the great programmers whose names you’ve heard. They can copy what’s already been done, and that’s it. Yes, they are “stochastic parrots”, regardless of what a Geoffrey Hinton tries to propagandize in his own favor (everyone has biases). By the way, as I’ve already said on podcasts: fuck Geoffrey Hinton. Stop falling for the Appeal to Authority Fallacy.

A Word to Companies

This should be obvious, but I’m going to put it on the record just so I can say “I TOLD YOU SO” later.

• No LLM is going to write code on its own. It needs a senior to spec it out.
• Every LLM-generated piece of code needs review. It needs a senior to review it.
• Part of the generated code needs to be rewritten. It needs a senior to know that.
• Another part of the code will have bugs the LLM will miss. It needs a senior to know that.
• Knowing what these bugs are, you can have the LLM fix them.

With that said, some things LLMs do very well:

• Exploratory analysis of legacy code
• Refactoring parts of legacy code
• Adding unit tests to parts of legacy code
• Suggesting improvements to parts of legacy code
• Finding some security or performance holes in legacy code

Notice how I say “parts” or “some”. There’s no guarantee it can do this on any legacy codebase or any part. Again, it needs a good senior evaluating each step.

Everything is done STEP BY STEP. An attempt, a check, an adjustment, repeat. It’s the famous PDCA cycle: Plan, Do, Check, Act. That’s the process that works. Every new tested adjustment becomes a “git commit” and we move on to the next step. Always one step at a time, systematically, in an organized manner. Never something generic like “Fix everything in this legacy system”.

Another thing LLMs are very good at is rewriting code from one language to another (translations in general). But I don’t recommend it, and not just because it’s an LLM:

I never recommend rewriting from scratch as a first option.

There’s no guarantee a newer language is “better” than an older one. “Better” always “depends” on your definition of “better”.

It’s trendy now to rewrite everything in Rust because supposedly it has fewer security problems. That’s incorrect. Rust is good for certain categories of security, not all of them. And there’s a whole category of functional problems that don’t show up in any compiler. Rewriting something complex, like a Linux kernel, in Rust is a gigantic illusion and a waste. If it “seems easy” to have an LLM rewrite it in Rust, it’s equally easy for it to fix a small bug in C precisely, without touching the rest that already works.

Rewriting is indeed a guarantee that several new bugs will appear and you won’t detect them right away; it’ll be a new time bomb. To fix one known bug, you ended up creating several other unknown bugs. Rewriting, by definition, always adds new bugs.

And no, when you ask the LLM: “find all the security bugs in this code”, it’s going to find some, but never all of them.

Understand Portuguese: it’ll always say something like “Here are all the bugs I found…” Even today’s LLM won’t try to say “Here are all the bugs that exist” anymore.

No AI is built to give 100% correct, unambiguous answers. On the contrary, it’s always a probabilistic machine that will give the answer based on the probabilities of the model generated by training. What’s not in that model, it doesn’t know. And even giving it context, there are no guarantees of “complete understanding”, only of “some understanding”. Always work with probabilities below 100%.

Programming languages, by their very nature, are not deterministic. There’s no way to write a mathematical equation where I can feed it the program and it guarantees the absence of bugs. This is a mathematical impossibility; it’s not “a matter of time”. Time is not relevant to that definition.

Bug detection (functional, security, performance, etc.) is always a stochastic process, a heuristic, never an algorithm. This is something every computer scientist or mathematician understands, but nobody who’s never studied can understand. For regular people, heuristic is the same as algorithm. That’s a mistake that can be fatal.

So, every LLM, by its very foundation and architecture, will always have these and other limitations built in. But that’s not a problem, that’s just the nature of the tool. Hammers aren’t meant to turn screws, and that’s not a flaw. It should be obvious, but hitting a hammer on a nail and not turning it is a natural characteristic. It’s neither an advantage nor a defect. It depends on what problem you want to solve.

Overall, LLMs will be very good at handling grunt work: adding tests, refactoring code, tweaking front-end, creating new screens from old screens, creating new reports from old reports. Creating Portuguese-to-Spanish translations of your system’s screens. For that kind of nail, LLMs are the perfect hammer.

Now, precise interpretation of laws, business rules, individual cases and exceptions to the rule, relaxing certain rules — everything that’s part of decision-making in a company. Never fully trust any LLM: you’ll need an experienced human to approve or reject. No matter how much it has memorized all the country’s laws, there’s no guarantee it knows when to use or not use them, and how that can vary in the most diverse cases, especially in the exceptions.

Never ask a hammer how you should run your company.

“How do you get seniors if there won’t be juniors anymore?”

Notice that the premise is that, at minimum, you’ll always need a senior instructing and reviewing the LLM’s work.

But if LLMs can perform all the grunt tasks that used to go to interns and juniors, how are they going to grow into seniors?

It’s the billion-dollar question and I’ll say upfront I don’t know the full answer. Nobody does.

The start is easy. It’s what I said in every video on the channel: it’s how I made my entire career: having a solid education and “learning to learn” for real. Easier said than done; that’s why I spent 5 years of videos trying to explain it in every way I could, to see if anyone would get it.

The next part is the hard one: how do you learn if LLMs already do everything?

This question starts from a false premise: LLMs don’t do everything. They do what they’re asked to do. If the request is well specified, it’ll come out like a gourmet dish from a 3-Michelin-star restaurant. If the request is lame, from someone clearly inexperienced, it’ll come out as instant noodles. It’s that simple.

The LLM’s result is directly proportional to the work of instruction, evaluation, and follow-up from the human in control.

“How is someone going to be a programmer if they don’t even know how to punch a card?” — It’s a fair question to ask someone in the 60s.

“How is someone going to be a programmer if they don’t even know how to save to a cassette tape?” — Another fair question, if it’s someone from the 80s.

“How is someone going to be a programmer if they don’t even know how to edit code in a text editor like Emacs and needs Eclipse?” — Another fair question, if it’s someone from the 90s.

“How is someone going to be a programmer if they don’t even know how to code for the Web?” — A good question for someone in the early 2000s.

“How is someone going to be a programmer if they can’t even build a mobile app?” — If it’s someone in the 2010s.

“How is someone going to be a programmer if they have LLMs?” — The question of the 2020s. Good luck.

Every generation has similar questions. None of them have an exact solution. Look at the facts: we’re still here. In 2026, I know things about programming I never dreamed I’d know when I entered college in 1995. Everything has changed. Everyone who “learned how to learn” knew how to ADAPT and use the knowledge they already had to learn new ways of working.

It’s all about adaptation: those who don’t adapt go extinct. That’s the law.

There’s not much more to say about this. But in practice:

If you’re a programmer, use LLMs. Learn their strengths and weaknesses, the different results they produce depending on your own knowledge, and never stop studying and training.

If you’re a senior/company, keep hiring juniors. Your seniors aren’t immortal. At the very least, eventually they’ll retire. More realistically: eventually they’ll change jobs. The second most important task of any senior is mentoring juniors and creating replacements. A senior incapable of creating their own replacement isn’t a senior, they’re a liability.

Mentoring is the same thing as always: training with follow-up and feedback, continuous improvement, with the difference that, besides operating system, text editor and IDEs, CI systems, etc., now there’s LLMs in the toolbox. That’s it. Don’t try to complicate what doesn’t need to be complicated and don’t suffer in advance.

Conclusion

“Ugh, but you said the AI bubble is going to burst.”

Yes, and I still say so. But you’re misunderstanding again. From 1994 to 2001 there was the Internet Bubble, and it burst!

Understand: the “Internet Bubble” burst. But the “Internet” still exists to this day. Is that clear?

Same thing: the “AI Bubble” is going to burst, many companies are going to go bankrupt, many people in the field are going to lose their jobs, etc. But AIs will keep existing. The AI bubble of the 60s burst, but AIs kept existing and even formed a new bubble now. Economic cycles have nothing to do with technological cycles.

It just means: “don’t bet all your chips on the same horse, especially if your life/career depends on it.”

LLMs will keep existing, roughly in the same form, a bit faster and more efficient, but with the same process behind them and the same way of working. Just like the Web of 2026 isn’t much different from the technology of the 90s, but is more refined and optimized.

I was never an AI “hater”; on the contrary, I’m someone who was already risking writing code with GPT-2. And it’s always improving. It’s now at a point where it’s easy to recommend even to non-programmers playing with systems that aren’t going to production and aren’t mission-critical.

Since I started with programming, at the end of the 80s, thankfully I’ve never had a single moment when I thought our field was “boring” or “monotonous”. For me, this is just another chapter in this story, and I’m expecting new chapters.

What I say that “sounds like hate” is just arguing and explaining the current limitations and the unrealistic expectations, illusions, or even blind bets I know aren’t going to pan out. I’m warning about what’s real. But I’m always saying: “there needs to be a new discovery”. With the expectation that something more is coming in the future, and not that “nothing’s going to work out”.

At the end of the day, the Java of the 90s didn’t replace the Cobol and Fortran of the world, as was intended. The Web didn’t turn into a peaceful utopia of pure knowledge as people wanted. Mobile didn’t replace other forms of computing as people wanted. VR didn’t become the new wave. None of that invalidates the qualities of Java, the Web, Mobile, or even VR.

The last Programming Bubble was a boring period for me in terms of innovation: because everything was being replaced by cheap programmers. For me, the bursting of that bubble was expected and makes me very happy. Because we finally came out of the drudgery of idiotic courses to talk about cutting-edge technology again. Programmers going back to being real programmers.

I only see good things in this.

By complete coincidence, this year I had the chance to appear on 3 podcast channels. I want to thank Paulo Silveira, Charles Max Wood, Lucas Caton, Fellipe Azambuja, and Ramon Sanches.

The first one actually came out late last year, in November, on Ruby Rogues with the topic “Ruby Conf Brazil and Building Communities” where Charles Wood and I talked a bit about the history of the Ruby community in Brazil — how I tried to get it started, what I attempted, the blog, talks, events. We also covered more specific points like a small overview of the Ruby language and my view on not limiting yourself to a single language or technology. If you’re new to the Ruby community, it might help give you an idea of how we got to where we are today.

The second one came out in February, on Paulo Silveira’s podcast Hipsters Ponto Tech, and the topic was “Carreira em Tecnologia”. The legendary Guilherme Silveira and Sérgio Lopes joined in, and in that conversation we touched on the main aspects for anyone starting a programming career. Take a look at the comments too, since several other points of view, opinions, and tips came in from listeners. Fun fact: this one was a bit of work because we recorded an earlier version, but since Paulo was still in the early days of the podcast, he refined the process and asked us to re-record the one that ended up being released. The format and topics changed a bit to be more focused, which made the conversation better. Some of the topics I covered in the first attempt I ended up revisiting in the podcasts later in this list.

The third came out in mid-May at the invitation of Lucas Caton, who introduced me to Montanha and Ramon from the podcast Dev na Estrada, and the topic was “Vale a pena? Ruby on Rails com Lucas Caton e Akita” where I again revisit some of the history of the international Ruby community and why Ruby on Rails is different from every other community, and why it’s still worth investing your time in this ecosystem.

The fourth came out at the end of May when Charles Wood invited me back to Ruby Rogues with the title “My Ruby Story”, but this time for me to tell a bit of my personal story. How I started my career. How I got into Ruby specifically. The historical context in the tech world over the past 20 years.

The fifth and most recent came out today, early June. I’m back again with Montanha from Dev na Estrada in an “Interview” to revisit some of the Ruby Rogues theme about the beginning of my career. But while on Ruby Rogues I move very quickly over the beginning and jump to the last 10 years where I focused more on Ruby, in this one with Montanha I focus much more on the very start of my career, particularly the 90s and a brush over 30 years ago up to 10 years ago. The earlier ones are long (about 1h each on average), but this one in particular is VERY long (almost 2h!) — apologies for the length. But Montanha started with “tell us from the beginning”… I tried to summarize and only mention a few points, but even so it ended up REALLY long!

Did anyone get to listen to any of the podcasts? What did you think? Leave your comments below.

Below, I’ll transcribe the professor’s questions and my answers.

Professor: My name is Rosenclever, I’m a university professor currently teaching Object-Oriented Analysis and Design (basically UML, Design Patterns, and Agile methodologies) and Object-Oriented Programming 2 (Java for Web with JPA and JSF)

Well, since you’re a developer who today also plays the role of an entrepreneur, and I, on the other hand, am in academia trying to prepare professionals to work in the market, I always try to update my content with market demand, and it’s very common to hear from IT managers, through the media, that there’s a very big gap between what’s taught in academia and what the market needs…

So I’d like to ask for your contribution so that I can help my students leave better prepared for the market. I’d like to know your opinion on the syllabuses of the courses I mentioned at the beginning of this email…

Professor: 1) Does it make sense today to master UML diagrams?

AkitaOnRails: “Master” perhaps not (in the sense of knowing every little detail of every diagram). But knowing they exist, having a general notion of each, and knowing the most useful ones like Use Cases, Sequence Diagram, State Diagram, Class Diagram, I think is appropriate and useful. And never as a way to design ALL the software, but a few parts that maybe become clearer if you diagram first.

Adding here in the post: plenty of people who never programmed professionally think that “any and every” type of diagramming and planning is unnecessary. They still imagine (without knowing it) that the so-called “corporate” world runs on mountains of diagrams and plans. That’s almost never true.

Of course there are exceptions, but in the common case a programmer needs to communicate an idea through something beyond code. That matters most when explaining a complex architecture to the team before starting to code.

It doesn’t mean diagramming 100% of the classes, 100% of the states, 100% of the sequences. It means diagramming what’s most critical and hardest to understand, and letting the rest emerge naturally during programming.

Professor: 2) Which Design Patterns and Agile concepts do you consider fundamental to be taught in academia? Or is that also not considered important?

AkitaOnRails: Design Patterns are important, but as a reference. They’re possible solutions, and they need to be evaluated case by case. In Agile, only worry about Extreme Programming, because all XP techniques matter. Scrum and Kanban can be introduced, but they’re dispensable. About patterns:

• Brazilian Portuguese Can Confuse Us: Standard vs Pattern
• GoF Design Patterns - Did it survive the test of time?
• Design Patterns represent defects in Languages

Adding here in the post: the important thing is to teach that nobody needs to invent everything from scratch all the time. That would be a redundant effort, since someone has probably already solved the problem before.

At the same time, it’s worth explaining that what we know today is just what seems to work best, and none of it is final. If someone has a result that beats what we know, great, show it to everyone.

It became fashionable to talk about “Inversion of Control,” and few people know what it really means. They only know it seems to improve “modularization,” also without understanding why modularizing is a benefit in some cases and not so much in others.

And speaking of Agile, I recommend reading these posts of mine:

• Lean is Dead, Long Live Efficiency
• Agile: the Truth Behind the Method

Professor: 3) Does the OO Analysis and Design discipline still make sense today? What would be interesting to be addressed in it?

AkitaOnRails: Of course, but today you have to emphasize that OO (object orientation) is one approach among several, and not always the “best.”

By the way, OO only gets interesting in academia through the eyes of languages that really explore OO, like Smalltalk and Ruby. It’s worth showing the whole landscape: class-oriented programming in Java and C#, functional in Lisp and Scheme, prototype-oriented in JavaScript and Io, and programming with concurrency and actors in Go, Scala, and Elixir/Erlang.

Adding to the post: this is the kind of subject with no “right” answer. Any attempt to measure the strength of one side or the other always turns into a flamewar or a mediocre bikeshedding.

The reality is that software factories will keep using languages with good commercial tooling support, like IBM Websphere and Microsoft Visual Studio.NET. Tech startups and smaller, more “best of breed” technology-oriented companies will prefer open source solutions that sometimes look like a “patchwork quilt.”

Agencies and small producers will keep using whatever delivers in the shortest possible time, even if it’s dirty. Advertising campaigns last very little, so you’re left with the “quick and dirty,” the WordPress derivatives, and so on.

Professor: 4) Is it definitely still worth teaching Java in academia? Do you think Ruby and Rails or even Python and Django are more appropriate?

AkitaOnRails: Yes, it’s worth it, as long as Java comes in as what it really is: the commercially most viable language. It isn’t the only solution to everything nor the best example of an OO language.

Ruby and Python can be explored as dynamically typed languages, taking the chance to explain the difference between static and dynamic typing. But in academia, especially in Computer Science, I’ve always been in favor of teaching dead languages like Smalltalk, Lisp, and Eiffel. That keeps the student from falling into the temptation of staying only with the language they learned in college. A bachelor’s degree should prioritize foundation, and commercial use is the job of technical and technologist schools.

Adding to the post: Academia, especially in Computer Science chairs, must emphasize science. Going 100% toward the market creates a generation that becomes obsolete very quickly and, worse, that never learns to update itself on its own.

In a hypothetical scenario, if 100% of universities turned 100% toward what the “market” wants, in ten years we’d have our entire computing field junked. Universities need to elevate the “Science” of Computer Science.

Let me leave posts I wrote about university and career topics:

• Should I go to college?
• Career in Programming - Coding isn’t Programming
• Letter to a Young Programmer Considering a Startup

Professor: Sorry for the long email, but unfortunately there was no opportunity for us to talk at the event…

AkitaOnRails: Not at all, if the subject is relevant, it’s worth discussing it. And I encourage everyone who attends events I’m at to call me if they want to discuss ways we can help improve education. This subject will never be irrelevant.

"Do what you love"/"Follow your passion" is dangerous advice and can destroy your career.

Another recognized celebrity in the US is Mark Cuban, owner of the Dallas Mavericks, who, in 2012, said the same thing:

"Don't follow your passion, follow your effort."

Apparently, the famous Confucius was the first to say the phrase that would become one of the biggest clichés for young people coming out of adolescence and having to face adult life with real responsibilities:

"Do what you love and the money will follow."

By the way, Confucius is kind of a generic for everything: don’t know who said it? Say it’s from Confucius. (And the usual disclaimer: just because I quoted people doesn’t mean I agree with them or with everything they say; they’re mere references!)

Besides Mark Cuban and Marc Andreessen, several others have raised the subject before, and I recommend you read “Don’t do what you love.” by cartoonist Rachel Nabors, where she concludes with a new phrase:

"Just don't do what you hate."

On the renowned site Slate, Miya Tokumitsu also wrote “In the Name of Love” where she begins with the excellent subtitle to the article:

Elites embrace the "do what you love" mantra. But it devalues work and hurts workers.

I have to say I was even a little surprised that this subject is also in Brazil. In March 2014, Daniela Carasco wrote the article “5 reasons why ‘do what you love’ is not the solution,” published by EXAME.com, talking about Bárbara Castro, a sociologist specialized in work issues and professor of the sociopsychology course at the Fundação Escola de Sociologia e Política de São Paulo (FESPSP). And she also already identified the obvious that many still remain blind to:

According to her, the big problem with the "love what you do" narrative is that it's tied to a discourse of happiness that means "being at the top of the rollercoaster all the time." As if a normal, day-to-day, routine life couldn't be a life of satisfaction. All of this makes this scenario worrying.

Finally, blogger Dani Arrais analyzed the subject in February 2014 in her post “THE TRAP OF ‘DO WHAT YOU LOVE’”, who coincidentally is also a friend of the same sociologist Bárbara Castro (something tells me I should try to meet her), and she says:

Do we need to be happy all the time with the work we do? Even if we love what we do? Can't we suffer with the contradictions that this work imposes on us? Why can't we admit that it doesn't make sense? Who does this interest?

You may be confused reading all this. I imagine the vast majority of my readers have always identified with the “Do what you love” mantra. After all, if you’re on a blog that talks about Ruby and, with less emphasis, technology in general and Entrepreneurship, it’s probably because you “love” the subjects of Ruby, Technology or Entrepreneurship.

And you probably read what I post because you assume that I’m “passionate” about these subjects. And here comes the important part:

• I don’t love Ruby or programming
• I don’t love entrepreneuring or owning a company
• I don’t love technology or the equipment I buy
• I don’t love writing or the time I spend on it

And to be honest, over the years, because of this so-often-repeated mantra, so many brainwashing attempts, a few times I almost succumbed and believed in this idea, but fortunately I always managed to bring myself back. And I have no problem saying that I don’t love any of these things.

But if that’s the case, you might want to ask me:

• Why so much effort writing so much about these subjects? (1000 posts!)
• Why so much effort working in programming? (almost 20 years!)
• Why so much effort organizing events? (7 Rubyconf Brazil!)
• Why so much effort traveling the country to evangelize these subjects? (more than 100 talks!)
• Why so much effort creating a company? (6 years in consulting, 3 years in my own!)

I’ll try to answer at the end. And there’s nothing wrong with what you think you like, love, or are passionate about. The idea of the article isn’t to say why that’s “wrong”; it’s just the way the phrase is used that I want to explore within my own personal context.

First of all, don’t follow advice blindly. The first time I understood this concept consciously was watching the famous viral video from the beginning of the century, Everybody’s Free to Wear Sunscreen, where one of the parts says:

Be careful whose advice you buy, but be patient with those who supply it.

Advice is a form of nostalgia. Dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts, and recycling it for more than it's worth.

That said, I don’t want to advise you on what to do, but I want to explain a few points that may go unnoticed.

First, the Obvious.

First of all, if you think “Do what you love,” you’re actually thinking “Do ONLY what you love.”

• “I don’t love waking up early”
• “I don’t love obeying orders”
• “I don’t love sitting in traffic”

And this list will grow, because there are millions of things we need to do but obviously don’t “love.” Deep down, the most generic would be: “I don’t like doing anything (working).” I just don’t know how that derives into the other great cliché of our times:

"I'll become my own boss to follow my own passions and not someone else's dream."

The irony is that if someone believes this, they’re already following the dream of whoever made that phrase for the first time. You’re already living someone else’s dream, whether you want to or not. Think about it.

Phrases like that naturally lead to other self-help fallacies. One of the most famous would certainly be the dreadful and dangerous “The Secret”, whose definition is as follows (according to Wikipedia):

The Secret states that the law of attraction is a natural law that determines the complete order of the universe and our personal lives through the process of “like attracts like.” The author claims that the way we think and feel, a matching frequency is sent to the universe and that attracts back events and circumstances of the same frequency. (…) and if you think positively, you’ll attract positive events and circumstances. The proponents claim that desirable results like health, wealth, and happiness can be attracted by changing your thoughts and feelings.

The idea of “doing what you love” is unequivocally linked with “thinking positive to attract positive,” even though, rationally, trying things like “dropping everything to pursue what you love” has the same odds of working out as winning the lottery. And whoever thinks this way should look at the child in the photo below and tell them:

"You certainly aren't thinking positive enough."

Exaggeration? Not so much, it’s the same result: you believed an idea blindly, without thinking about it. We do this every day, and I know it takes a conscious, big effort not to be a victim of it. I myself almost believed these ideas before.

Hold what you want to troll in the comments right now: I’m not saying that thinking positive is wrong, that pursuing your dreams is wrong, or that doing what you like is wrong! Follow to the end.

Second, What Do You Love?

What’s the difference between Passion and Love? And what is Passion? And what is Love?

These are questions humanity has already spent millennia exploring and will have to explore for more millennia. How many poems, literature, songs, paintings, sculptures, speeches, revolutions have already happened because of Passion and Love? This post on a mere blog will not be where you find an answer, and this author doesn’t even presume to imagine he knows the answer.

But for the sake of continuing this text, I like this brief summary:

• Love is a state of way of life, while passion is a state of being.
• Passion lasts for a short time, but Love lasts longer.
• In Love, deep understanding is the essence, while passion doesn’t require it.

Reread the phrase “Do what you Love,” or similar ones like “Follow your passion.”

You are passionate about or love many things at the same time. And this changes over time. You rarely find something or someone you’ll love forever (and you’ll only know it close to your death).

ONLY following something that changes all the time is a race without purpose. And the only guaranteed result is that you’ll get frustrated in a worse way.

But does that mean we should ignore our passions? Of course not. I’m just saying that thinking your life should be filled only with what you’re passionate about, ignoring the rest of the world, is an absolutely childish stance.

It’s like any child excited about the Nintendo 64, who goes days without bathing, without sleeping, without talking to anyone, without wanting to go to school, because they’re deeply passionate about it. And, as we all know, most get bored in a few days. Weeks later, the so-passionate object of desire is in a corner of the closet gathering dust, and the child is already looking for what to love next, every children’s day, birthday, and Christmas.

Doing “ONLY” what you “THINK” you “LOVE” (note the emphases in this phrase) means simply ignoring the real world. Ignoring brushing your teeth, ignoring going to school, ignoring working, ignoring responsibilities, which is what every adult would call “still being a child.”

Third, What Do I Love?

Talking this way sounds like another cliché: that an adult is a child who has set their passions aside. That’s perhaps where the later evolution comes from, with 30-year-old “adults” still trying to be the same children they once were.

This usually means being irresponsible, egocentric, and anti-social, since the so-called “adult world” demands responsibility, collaboration, interaction, and commitments. No one “loves” that kind of thing, no one loves “negotiating middle ground.” Every child wants all or nothing.

If you’re a reader who has followed me for the last 8 years, up to this post 1001 (which my friends have affectionately pre-nicknamed as the “Bombril post, of 1,001 uses”), maybe you have an idea of what I want to say now.

And here comes a disclaimer: don’t quote me as saying this is the solution or the answer. What I’m about to say is absolutely personal.

I do indeed pursue some of my “passions.” Like every human being, I get passionate very easily about a lot of things. It means I also get frustrated a lot, all the time. I’m human: cut me and I bleed. And much of what I like is superfluous, and the difference is perhaps that I’ve long understood that they’re superfluous. That is, I make mistakes, trip, fall, all the time, and I learn how to get up every time.

I’m passionate about technology, programming, methods, processes. And at the same time they frustrate me, upset me, leave me frustrated, leave me irritated and wanting to throw it all away. As every passion always is.

I’m passionate about communication, sociology, people, sharing knowledge, whether writing or speaking. And again, this leaves me tired, stressed, frustrated when I’m not understood, upset when people assume things without asking, but again, it’s how a passion should be.

But as I said at the beginning, I don’t Love any of these things. They aren’t my “life goals” or definitions of my identity or any philosophical thing of that kind. They are things I like, that I pursue, that bring me both pleasure and suffering at the same time, and that are means to another end, which isn’t to make me “happy” (in the sense of being comfortable in the short term, as it is for everyone).

Being happy all the time is the realm of LSD addicts. Have you ever seen someone who is honestly happy 100% of the time? That’s impossible. And thinking your work should be your greatest passion will only bring as a result a state of misery and frustration that’s the realm of psychologists and psychiatrists, the realm of tranquilizers and antidepressants.

(By the way, if I were neurotic, I’d almost conclude that self-help phrases like the one discussed here are a Psychiatrists’ Conspiracy to generate more Depressives. #troll)

No one should ever be “comfortable” or “happy” 100% of the time. Passions, Love, Happiness are always a dynamic balance between things that satisfy you and things that don’t satisfy you. You can’t have Light without Darkness existing. You can’t have satiety without hunger existing. You can’t have warmth without cold existing.

Another derived phrase is “Love what you do,” but that’s an exaggeration. I think of it another way that I think my mother told me for the first time and that is true:

"It doesn't matter what you're doing, but since you're doing it, do the best you can."

Confucius didn’t only say the phrase that gives origin to this post. Perhaps you remember Confucianism and that the ancient Easterners may have already defined this better: Yin and Yang, the concept of how opposite or contrary forces are actually complementary, interconnected, and interdependent in the natural world, and how one gives rise to the other. Yin and Yang can be seen as complementary rather than opposite, interacting in a dynamic system where the whole is greater than the sum of the parts.

Without ever having suffered, how is it possible to know what happiness is?

My Conclusion

In the end, Ruby, programming, technology, projects, entrepreneurship, talks, blog, and all of this are just means that don’t define what I really like and always liked: learning and improving myself, purely.

If you’ve at least once heard of Agile, Lean, Kanban, Toyota (recurring themes on this blog), you’ll remember the Japanese concept of Kaizen (改善) or “continuous improvement.” For me it’s something conscious. I remember as a kid seeing a very simple thing in an allegory: how does a ninja jump so high and even over a tree (in cartoons)? Simple: he starts by jumping a little bush on the ground, then a small shrub, and so on.

Perfection isn’t an achievable goal; continuous improvement is the infinite process for an unreachable goal. And what I love is the challenge of improving one aspect at a time in each of the capabilities I have today (programming, communicating, teaching, producing).

My foundation is that I’m passionate about producing, and everything I produce is nothing more than a draft of the knowledge I have today, and always worse than I can produce tomorrow. My only, true “passion” is the certainty that I will never really be “good” and that I am today a little better than I was yesterday. That’s all. It doesn’t matter now whether I’m doing a programming project or writing this post or if tomorrow I decide to paint paintings.

Learning means I don’t like easy things. Anything that everyone says is hard, boring, that they would never do, or that they can’t do, naturally attracts me. Because I like to solve problems, which is one of the best ways to test what I know. Doing what everyone already knows gives me no pleasure.

In particular I like producing something that is useful to someone. Whether it’s a post or a talk that helped someone learn something, or a work opportunity someone can use for their own goals, or a project a client can use to reach their goals.

Deep down, I have the impression that if I could summarize it, I love and am passionate not about the “what” I do but the “how” I do it. Especially when there are obstacles in what would be the “ideal how” and how I can solve that problem to reach the “what.” The “what” isn’t the part that interests me most.

The phrase “Do what you love” is always taken as “Do ‘only’ what you love,” and what I wanted to summarize was: “Don’t do ‘only’ what you ’think’ you love.” That’s all.

My only inviolable principle is to live through voluntary exchanges for mutual benefit. That’s why nothing I say is absolute and inviolable truth, but rather teachings on how to think, how to counter-argue, how to be conscious, how to be an individual who doesn’t live by others’ clichés. I don’t want blind followers in the same way that I don’t want and don’t need charismatic idols to follow.

I hope this can be my legacy.

You can take some initial knowledge, say web and HTML, throw in a few frameworks and libraries (Rails, Django, WordPress), and actually put something functional online. But that’s little. Very little.

The fact that it’s so simple, bordering on trivial, to put “something functional” online hides all the potential in a programming career. Worse, the immediacy of the result creates the illusion that this alone is enough and that any more advanced knowledge is unnecessary.

The result shows up in the growth of technical programming courses and the low demand for Computer Science bachelor’s degrees. The fewer people we have working on the fundamentals, at the origin of everything, the more the market decays from here on.

You have a coder job today: Photoshop cutter, HTML assembler, WordPress plugin-sticker. Stop and think about how your career is going to evolve from here. Are you always going to be just an assembler? Are you going to take the easy path and become a half-baked “manager” of assemblers?

In a single post it’s impossible to list and explain every important aspect of Computer Science. But I want to try naming at least some of the subjects most people think are unnecessary, just to provoke you into digging further.

Learn to at least “READ” English fluently

I love the Portuguese language, and it will always be my first language. But pseudo-patriotism and laziness don’t change one fact: if you don’t commit right now to reading English fluently, you’ll live behind, at a sorry level.

The first reason is that in the Western world, everything new comes out in English first. (I’m leaving out the East because I don’t read Chinese, and the market there is enormous too.) Waiting for someone to bother translating it costs work and time.

If you rely on the Portuguese version, you’ll be reading stale material. And by the time the subject finally grabs you, it may already be obsolete. At that point the gap stops being one step and turns into hundreds of kilometers.

The second reason is that the internet is globalized. It’s common to pick up code written in other countries and carry it forward, and it’s common for the code you write to be shared with programmers abroad. Do yourself a favor: don’t embarrass yourself.

Religious Wars

Programming is science. It has no horoscope, no guru, no soccer team, no numerology, no astrology. Remember the name: Computer SCIENCE. Nobody calls it Computer Astrology.

Everyone has subjective tastes. Turning taste into dogma is stupid. The laziness of having to learn something new produces the famous “I’m good at Clipper, this language will evolve in the future and will always exist, I just have to defend it tooth and nail no matter what comes along later.”

Swap “Clipper” for anything else: Cobol, Basic, Pascal, Algol, Eiffel, Smalltalk, all the way to the newest ones like Java, C#, JavaScript, Python. Something existing today guarantees nothing about tomorrow. Think about how ridiculous whoever said that line must feel now.

Don’t play that role. In Science we’re not loyal to “teams”: we root for whoever is winning and switch the moment they’re proven wrong. That’s why Science always evolves.

And surprises happen. In the 80s and 90s nobody gave Objective-C a second look; it seemed doomed to failure. Then, in 2007, the iPhone shows up and, surprise, you needed to know Objective-C. Suddenly it became one of the most successful languages of the end of the first decade of the 21st century. Every ten years the market transforms in some way. It’s Bell’s Law.

Accept It: Your Solutions Today Are Bad

Back to the theme of “Ignore the Religious Wars”: how do you figure out what to do? Stick to the principles. Throw out what the gurus say, don’t idolize anyone, don’t blindly follow anyone. Go down to the fundamental questions and the more obvious direction shows up.

When you know how things work, strip the varnish, pop the hood, take the engine apart, understand the chemistry of combustion, only then do you master the craft. If you barely remember what the hell changing the oil is for, you’ll always be a mediocre driver, at best. What’s your goal? If it’s to be the car’s engineer, listening to gurus talk about the color of the steering wheel won’t take you far.

Computer Science usually gets ignored because learning Math looks both boring and useless.

Let’s run through a few examples. If I ask a beginner how to search for words inside a text, the most obvious things that should come to mind are:

• use substring functions and a loop to scan the text (brute-force solution)
• use a regular expression, or in a database use a “LIKE” (generic solution)
• install a SOLR or Elasticsearch (correct solution in many cases, but “black magic” in terms of understanding)

Most people wouldn’t even think of the third solution. And whoever does doesn’t know why. What if I told you that, in an absolutely raw and boiled-down way, the solution is to turn the document and the search terms into vectors and compute the relevance between them by cosine similarity? That’s exactly what the Vector Space Model (VSM) means, which you’ll find in several search engines.

The knowledge behind that is called Linear Algebra. Remember it, from the FIRST year of Computer Science? On this topic I recommend a talk I gave, “How not to do searches using LIKE”.

And when you need to build a process to filter inappropriate content? Most people would think like this:

• create a blacklist of words and keep adding to it as offensive words come to mind. And use the first or second option I listed before to search for those words.

As you can already imagine, the most “obvious” or “simple” answer (given the lack of knowledge) is usually the wrong one, and here it also isn’t the most efficient.

Get to know machine learning and one of its simplest forms, the Naive Bayes Classifier. Someone might think “damn, but this machine learning stuff is way too advanced for the day-to-day.” Not at all. In fact, any cheap anti-spam filter you find on a free-downloads site uses a classifier.

The idea is that isolated words aren’t enough to tell whether content is inappropriate. The way sentences are built, the “tone” of the writing, all of that forms a pattern that can be classified and learned. The more inappropriate content gets classified, the more efficient the algorithm becomes.

If you want to try a simple version in Ruby, see this blog. If you want to learn about more advanced classifiers, see the Apache Mahout project.

And what is that? It’s a subject of Statistics and Probability. The fundamentals for understanding it are, again, in the FIRST year of Computer Science.

“Oh, but you’re talking about things nobody needs to know. To make websites this is unnecessary.”

A good web framework needs to map routes to the underlying programming (the controllers) efficiently. Ruby on Rails has a routing component called Journey, which we configure through the “config/routes.rb” file. Below is an excerpt:

ImageUploadDemo::Application.routes.draw do
  devise_for :admin_users, ActiveAdmin::Devise.config

  resources :photos

  authenticated :user do
    root :to => 'photos#index'
  end
  root :to => "photos#index"
  devise_for :users

  require 'sidekiq/web'
  mount Sidekiq::Web => '/sidekiq'
  ActiveAdmin.routes(self)
end

How hard can this be? What might most people imagine?

• Easy, just make a set of arrays or a hash (dictionary), and when the URL arrives, break the terms with a regular expression and find the controller, passing the parameters to run it.

Let me repeat myself: yes, this works, for very small applications. Anything much bigger than the example above already runs into performance problems.

How about a look at a snippet of the Journey code?

class Journey::Parser

token SLASH LITERAL SYMBOL LPAREN RPAREN DOT STAR OR

rule
  expressions
    : expressions expression  { result = Cat.new(val.first, val.last) }
    | expression              { result = val.first }
    | or
    ;
  expression
    : terminal
    | group
    | star
    ;
  group
    : LPAREN expressions RPAREN { result = Group.new(val[1]) }
    ;
  or
    : expressions OR expression { result = Or.new([val.first, val.last]) }
    ;
  star
    : STAR       { result = Star.new(Symbol.new(val.last)) }
    ;
  terminal
    : symbol
    | literal
    | slash
    | dot
    ;
  slash
    : SLASH              { result = Slash.new('/') }
    ;
  symbol
    : SYMBOL             { result = Symbol.new(val.first) }
    ;
  literal
    : LITERAL            { result = Literal.new(val.first) }
  dot
    : DOT                { result = Dot.new(val.first) }
    ;

end

In plain English, now you’re screwed. Part of Journey uses Racc, a parser generator.

If you made it at least through the SECOND year of Computer Science, then you went through Algorithms and Data Structures and Assemblers. And if you reached the THIRD year, you learned about Compilers (and saw the famous Dragon book). Racc should have reminded you of Yacc, Flex, Bison.

To wrap up, you probably think you know what Object Orientation is, right? I bet you consider your favorite language (whether Java, C#, or JavaScript) object-oriented. If I ask you to define what that means, it’s on the tip of your tongue:

• My language supports Encapsulation, Inheritance, and Polymorphism, therefore it’s object-oriented.

And what if I told you that procedural, imperative, and functional languages also support encapsulation, inheritance (via delegation or not), and polymorphism? And if that’s the case, then what defines object orientation?

Whoever got into the subject might remember Alan Kay, who coined the term “object orientation.” But how many stopped to research the Simula 67 language? What did Simula introduce in 1967? Objects, classes, inheritance, subclasses, virtual methods, coroutines, discrete event simulation, garbage collection.

And how many have heard of the creators of Simula 67, Kristen Nygaard and Ole-Johan Dahl?

You don’t know who they are? I’m sure you don’t. Well, let me introduce you to the fathers of object orientation.

On the Shoulders of Giants

What I mentioned in the previous section is a drop of water on the tip of the iceberg. What matters is for you to realize that everything you think you know is close to nothing. I want you to accept that everything you think you know is either wrong or totally incomplete.

That matters because whoever thinks they already know everything, or close to it, will never learn anything. You need to empty the cup to fill it. (by Bruce Lee)

Beyond that, I want you to understand you’re not alone. Before you came dozens of great minds. And I’m not talking about those superficial gurus who merely teach techniques and tools. Forget them, everyone will forget them soon too.

Everyone knows who Linus Torvalds, Bill Gates, Steve Jobs, Zuckerberg are. Forget them for now. Stick to the immortals, the names who really made a difference in the history of Computer Science. A few examples:

• Charles Babbage
• Ada Lovelace
• George Boole
• Alan Turing
• Alonzo Church
• John von Neumann
• John McCarthy
• Niklaus Wirth
• Bertrand Meyer
• Dan Ingalls
• Donald Knuth
• Edsger W. Dijkstra

And that’s just a sample. Science is a broad field, where one scientist’s work complements the previous one’s. Step by step, always moving forward. It’s a cumulative work of tens, hundreds of years. Our advantage? Hundreds of people already walked this path in the past, and we can use what they learned and left us, instead of making the same mistakes ourselves until we learn on our own.

Almost everything you see out there called “innovation” is the rediscovery of things already documented in the past, but that were ahead of their time. It was like that with the mouse: Douglas Engelbart, who created it in 1968, had to wait sixteen years, until Steve Jobs launched the Macintosh, to see his invention go mainstream. Stop and think: how many discoveries are sitting in the past, just waiting for someone to dig them up and finally make them real?

Want to know about the immortal books of Computer Science? Here are a few:

• Structure and Interpretation of Computer Programs (SICP)
• The C Programming Language (K&R)
• Algorithms + Data Structures = Programs
• Compilers: Principles, Techniques and Tools, the Dragon book
• Modern Operating Systems
• Computer Networks
• The Art of Computer Programming, which even I haven’t read, and I don’t know anyone who has read and understood it, but I’ll leave it here because of its importance.

Don’t want to go to college? No problem, try to follow the material MIT makes available online on Electrical Engineering and Computer Science. If you’re still a complete amateur even in the programming world, see this introductory Computer Science course on Coursera.

Note that I’m not citing in this article any of the names many might expect, like Martin Fowler, Bruce Eckel, Robert Martin, Michael Feathers, Kent Beck, Steve McConnell, Tom DeMarco, Dave Thomas. Forget them for now. Without the earlier ones, these make little difference.

Don’t put the cart before the horse. Go one step at a time.

Career in Programming

One thing I always repeat is this:

"Programming isn't writing any code, the same way cooking isn't throwing any ingredient into a pan."

Understand: writing code is very simple. Anyone with the minimum motor coordination not to try shoving a square peg through a round hole, or who has at least stacked one Lego brick on top of another, is capable of writing code. There’s no merit in it at all.

Downloading a Twitter Bootstrap, using a Yeoman generator, installing MySQL on Ubuntu, copying and pasting a jQuery snippet: anyone can do it.

In career terms, what “anyone” can do is a mere “commodity”. Being a commodity means the value the market is willing to pay will only drop. Every so often some novelty shows up trying to create a differentiation (“look, Angular JS,” “look, HTML 5”), but it quickly dissolves into the downward trend in value.

Value lives in the creativity of the solution: extracting the greatest result for the lowest cost. And creativity only exists when you master all the elements around you. When one hour of work swaps an idiotic word-search algorithm for a vector space model, cuts your fleet from ten machines to two, and answers your user in a fifth of the time, that’s applied knowledge. And knowledge like that has value, and it grows.

A full toolbox makes you a “jack-of-all-trades with many tools.” The engineer or architect capable of building the next World Trade Center or Freedom Tower is a different thing.

But, like everyone who wants to grow, we all start as jacks-of-all-trades. There’s nothing wrong with that. Just don’t fool yourself into thinking that a box with more tools turns you into anything different from that.

Recently a blog article kicked up some buzz. Titled I wanted to work at Apple really bad, and now not so much, it’s a vent from the author himself. The summary is simple: in his opinion, his boss treated him and his team badly, to the point where he dropped everything and walked out.

The more generic discussions ran along the lines of how Apple must really be a horrible place to work, and that the upper ranks still practice the legendary “Steve Jobs style” of kicking people to squeeze out results. Some even went so far as to say “the only way out is to start your own thing, chase your own dreams without a boss like that stepping on you.”

And that’s the point of this article. With the current frenzy around startups, this is an attitude I see more and more often.

Let me put the common complaint about bosses in perspective. No boss you’ve ever run into, even the worst of the worst, comes close to Henry Clay Frick, who ran the operations of legendary Andrew Carnegie’s steel mills. Working conditions in the late 19th century were terrible, and maybe not even the worst conditions today match the worst of that era.

Several of the great industrial magnates of the period, including Carnegie, Rockefeller, Vanderbilt, and many others, exploited workers to the edge of misery. One example of how far it went was the famous Homestead Strike. The result? Seven workers killed and eleven wounded.

Believe me, you would not want someone like Frick as your boss.

That was an extreme example, and it doesn’t mean there aren’t bad bosses today. I’ll keep the context to the world of tech startups we’re part of, and leave out public service, the military, and other areas outside that frame.

The big difference between today and Carnegie’s time is that today there are options. Back then, either you put up with terrible conditions and terrible pay, or you lived in misery with no job at all. Today any good professional has plenty of alternatives. People come and go from companies hundreds of times a day, across hundreds of companies, and you only have to look at the proliferation of job and recruiting sites to see it.

If you’re a student or a fresh graduate, understand a hard truth: you are just like the hundreds of people who graduated alongside you and enter the market every single day. The first job is always hard. And not just the first: the second, the third, and probably the ones after that too. What you “think” you’re capable of is worth nothing until you have a run of concrete results to prove it. That’s what we call a résumé.

I’ve heard plenty of young people say things like “I need to change jobs, I’m not learning anything here anymore.” If you’ve been at the same company for ten years, it’s probably past time. In the first or second year? That’s nonsense. The company has plenty to teach you; the problem is you don’t want to learn.

A programmer, for instance, doesn’t have “programming” as their only job. In August 2013 I wrote that the hardest thing for a Software Engineer is to grasp that software problems often have no solution in software. Learning to negotiate, communicating so others actually understand, managing expectations, working in teams, convincing others that your ideas are good: all of that is part of the job.

In other words, a lot of things that have nothing to do with code. And this holds for any profession, whether you’re a designer, a writer, a cook, or a race car driver. Everyone has to learn and practice these skills to grow.

There are catchphrases repeated thoughtlessly, like “it’s not worth living someone else’s dream as a company employee.” If that’s the thinking, better to resign. A company isn’t a charity: it exists to turn a profit, not to babysit employees. And unless we’re talking about a non-profit, no employee is there as an unpaid volunteer.

Between company and employee there’s a work contract. Both agreed to the terms. If you don’t agree, don’t accept it; if you accepted, honor it; if you think the situation has changed, renegotiate. Renegotiating is an option, and the company can say no. If you’re not satisfied, resign, honor the terms to the end, and leave like any good professional. Walking off the job, like in the blog account, is a unilateral breach of contract. It’s wrong.

You have several reasons to hold a job. There’s the salary to pay the bills at the end of the month, assuming you’ve grown a spine and stopped sponging off mom and dad. And there’s the learning: you’re paid not only to do your job, but to explore everything established companies have already figured out, which you soak up “for free.” Every criticism you get, every complaint, is a chance to sharpen something you didn’t even know you were missing. “No pain, no gain.”

The very fact that you struggle to find another company willing to hire you already shows you’re still short on skills. Another common line is “I’d do more, but nobody gives me a chance (or pays me more).” If you’ve caught yourself saying that, you still have a lot to learn. And even to be an entrepreneur, this is the most basic lesson: nobody gives you anything for free, everything is a voluntary trade for mutual benefit. No benefit, no deal.

And I’ll tell you the worst place in the world to learn all of this: your own first company. The most common outcome when someone completely inexperienced decides to open their own shop? Becoming exactly the kind of boss described by the blog author who worked at Apple.

PS: there were plenty of ways the blog author could have solved his internal problem. A company the size of Apple, with more than 80 thousand employees, surely has several paths to solving a problem like that. Not knowing how to find them only shows there's still a lot to learn. After all, the squeaky wheel gets the grease.

For a change, SoHo is one of those subjects most of us only think about at the surface before deciding “it’s good” or “it’s bad.” It’s bad that Marissa Mayer banned Home Office. It’s good that 37signals is evangelizing Home Office. It’s bad that Microsoft agrees with Home Office, but with a possibly dystopian view. Worth remembering that the industry has been chewing on SoHo practically since the personal computer showed up in the mid-80s. There’s nothing new about it.

A disclaimer: I own a software shop, a company that offers development services. The core of the company is programmers hired not only in São Paulo, where I live and have clients, but also in Porto Alegre, Fortaleza, and Natal. I don’t intend to get into my process in this article.

I thought about dissecting the book Remote, which is the reference of the moment. But there isn’t much to dissect. If you read the table of contents, you basically know everything the book says already, and the rest is filler. Look:

• The Time Is Right for Remote Work: it lists everything we already know as the downside of big offices, the long meetings, the interruptions, the commute, the quality of life. Without reading the chapter, we already know what bugs us. The problem is that this is hard to argue against, because any place has things you like and things you don’t. Listing only what you dislike isn’t the most relevant thing. If you have a girlfriend or you’re married, did you make a list of your partner’s traits stacked up against Miss Universe or Mr. Universe? Is it the set of things that annoy you that matters, or the set of things you love?

• Dealing with Excuses: again, the “arguments,” the “demagoguery,” the “rhetoric” assumed to be the excuses managers and company owners use to block remote work. Half of them don’t even come out of the companies’ mouths; they come from the motivational self-help crowd, along the lines of “working close together boosts information exchange and therefore creativity.” The other half are policies like data security, customer service, loss of control. Those items are secondary. As a company owner, almost all of them are easy to handle and agree with. The industry isn’t that bad, and none of these points slipped by unnoticed over the past few decades. There are still leftovers, no doubt, but compare today with 20 years ago and you’ll see the difference.

• How to Collaborate Remotely: it sums up what we already know, that technology shrank distances. Skype/Hangout, Basecamp/Tracker/Asana, Github/Bitbucket, IRC/Campfire. On top of that, plenty of outsourced services are already remote. An accountant is a good example, and I’ll circle back to it later, so hold that thought.

• Beware the Dragons: the one part that “balances” the book and admits remote work isn’t always a bed of roses. Not feeling lonely, not working more hours than you should, keeping healthy habits. These are tips that apply to remote work and to anybody’s routine. Bottom line: use common sense, but you already knew that.

• Hiring and Keeping the Best: in short, and here I agree, there are excellent professionals in every corner of the world. That’s my reason for looking beyond São Paulo. Again, it’s easy to evangelize an argument without weighing every angle. I agree with the idea and I’ll come back to it later.

• Managing Remote Workers: once more, management common sense. Good managers already know this. We’ve had multinationals running on every continent for decades, and we’re good at it. A lot of people believe companies reject remote work because they don’t know how to manage people at a distance. That doesn’t hold up: look at the massive movement of outsourcing services to countries like India. Like the newspapers, we only look at the bad news, but we know how to do this, and it keeps getting simpler. Outsourcing to individuals looks more complicated than outsourcing to branches in other countries, but overall the process is the same.

• Life as a Remote Worker: more common sense for anybody. Have discipline, build a balanced routine, set aside time for your family. The only genuinely relevant bit is the last one, “make sure you aren’t being ignored.” That’s my central point for the rest of the article, so hold on to it.

To wrap up: of the 37signals books I’ve read, this is easily the weakest. When reading the table of contents is enough to grasp the whole book, the conclusion comes easy. That doesn’t make it wrong or bad, but a blog post could carry the same message: yes, there are plenty of advantages to remote work. And, of course, by pure coincidence they sell tools for exactly what the book describes. It’s a terrific piece of self-marketing, and it’d be dumb not to do it.

The Truth About Remote Work

Now for the other side of the coin. In my recent article Math, Trolls, Haters and Internet Discussions I tried to get across a simple but important idea: an incomplete formula is useless. To recap, a procedure, a methodology, or a process only becomes a “formula” once it defines the “domain” of the problem.

I’ll assume 37signals is arguing that service professionals could work remotely. I’m restricting it to computing because plenty of other fields simply don’t work that way, like airline pilots, firefighters, doctors. The domain is limited to services, never production, and whose output doesn’t need physical media, meaning it travels over the Internet. Musicians, programmers, writers, accountants, lawyers, architects (partly). Simple enough to define. For my purposes, I’ll stick to software development services.

The biggest problem with books and people who evangelize about human behavior is ignoring Sociology, Psychology, and the fields that already studied this thing to death. The book Remote is convenient for 37signals’ domain and works there. The way it’s described, it works only there. That’s the first tell for separating serious research from self-help: “It worked for me, so it can work for you.” That’s how they sell diets.

For several reasons, 37signals did very well as a product company. Among them, the ones Zed Shaw explains in this talk and the capital injection from Jeff Bezos. Good for them, but it means the problem domain is “product company that brings in revenue and profits very nicely.” And that already knocks a huge slice of the market out of the equation. If you don’t know the numbers, we’re talking about a much bigger universe, one that in Brazil came close to R$ 37 billion. Way bigger than the narrow universe of tech startups.

Worth understanding another thing that both Getting Real and Remote try to argue, and could have simplified. Highly centralized structures, with heavy top-down control and little or no regard for the workforce, tend to be bad places to work. The hasty conclusion is that full decentralization is the best form. Worse still is picturing 37signals as a decentralized company just because everyone is remote and there’s no rigid hierarchy. In practice it’s centralized, with intermediate levels of decentralization.

It gives the impression of a decentralized organization because it uses open source processes for execution. But the chain of command is clearly centralized in Jason Fried and David Hansson. There’s nothing wrong with that, and it’s exactly how it should be.

With that in mind, I want to show a chart I pulled from a Nicholas Christakis lecture. He cites a study on Broadway shows. Some are big hits, others are box-office flops, and the researchers wanted to know whether there was any correlation between the type of social network in the show’s organization and the success rates.

Picture on the X axis the density of relationships among the show’s team professionals. 0 is the highly centralized network, where people at the edges don’t even talk to each other; 100 is the highly decentralized network, where anyone talks to anyone. Level 0, intuition already flags as bad, and the correlation confirms it: it shows up in the shows that flopped. The counterintuitive part is that fully decentralized networks flop just as much. The successful shows sit in the intermediate networks, with some decentralization and some centralization.

37signals isn’t fully centralized, since the remote programmers talk over chat, via Github, and so on. And it isn’t fully decentralized, because there’s some level of specialization and, of course, a central strategic command.

I’m testing different scenarios, and the first step, in my case, starts with this other diagram:

But, as I said, I won’t stray from the main subject here. Just a hint.

The Career Problem

I keep repeating that defining the domain matters because, in 37signals’ case, you can raise people’s salaries almost indefinitely. The product already hit a scale where revenue is orders of magnitude larger than costs and expenses. Well, if you can bankroll racing at Le Mans, you can pay programmers 5 or 6 figures.

Keep evolving the product, build new products carefully, keep old customers happy, do good marketing to draw new ones, in short, what a good company should do, and you can keep growing for a good while.

Except a product company like that isn’t common. It’s actually the rarest case in the industry, and the same rules don’t apply to service companies, which are the majority. And the reason is structural, tied to the fundamentals of the industry.

From that comes the reasoning: “That’s why opening a service company isn’t worth it, better to go straight to products.” My answer is simple: “good luck.” The obvious premise is that product companies pan out right away. I already covered this in my previous article Tech Startups, B2C overcrowding. Boring..

“Oh, just follow Lean Startup, Agile processes, Business Canvas,” and the whole little package they sell today, with instructions any kid can follow and batteries included, and boom, automatic success… does anyone really buy that nonsense?

Now back to reality. The biggest problem with hiring home-office programmers is HR and career management, not just control. We’re reaching a maturity level in software development where programming with good practices, good technology, efficiency, predictability, and easy future maintenance stopped being a Premium and became the norm. I won’t offer a client a cheaper programmer because they’re low quality. I want my junior to move up to mid-level fast, the client to get the same technical level no matter who does the work, and the quality to stay above average, because the industry average is still below the poverty line.

Except, if that’s the norm, how does a company give programmers raises? Up to a point, technical ability makes a big difference. But cases of very high, still-experimental technology, where few people know what to do, are rare, in services and in products alike. The rest gets commoditized fast. The open source world all but guarantees that once a hard problem is solved, it gets replicated in no time. If making a responsive, halfway good-looking web front-end was once “complicated,” a Foundation or a Bootstrap already flattened most of that curve.

This is the core of the issue: just programming is too little for 90% of software projects. I discussed in another article, Estimates Are Promises. Promises Must Be Kept., that the hardest thing in a Software Engineer’s career is realizing that much of a software project isn’t solved with software. A “senior” professional is defined less by the prettiest code and more by managing client expectations, whether corporate or consumer, and by taking on responsibility.

Again, I won’t get hung up on exceptions like research centers or established products. Inside a group, properties emerge that only exist inside a group. (See the Christakis talk again, or others like Duncan Watts, to start getting a feel for these properties.) These are activities that usually don’t happen solo: peer-to-peer training, where a junior gets to learn from someone more senior, plus the exercise of communication, negotiation, responsibility, and teamwork.

All of that is possible while remote, just much slower and much less obvious, because each individual really is isolated. A geographical cluster also influences the market and the local community around it, so it isn’t confined to your primary group: secondary groups emerge. And each cluster relates the way Remote itself describes, with online tools and the occasional in-person trip.

In practice, how much more productive and efficient is a good senior developer than a junior? Ten times, tops? Meaning if a junior earns 1000, a senior earns 10,000 at most? And after that? Now, a good professional who trains, mentors, and self-scales from 1 to 3 has already climbed orders of magnitude. They easily reach 20,000 or more that way. Do this across clusters and soon you have a more resilient network.

I’m not saying mentoring only happens in person, but the people who can pull it off remotely are still the exception, not the rule. We hire folks with little experience, or fresh out of college, and mentoring that person at a distance, while not impossible, is tricky. In the end, it always comes down to the person.

So is an individual working remotely wrong? Of course not. That’s another problem with this kind of argument: it makes it look like there are only two paths. As with everything in sociology, there are many scenarios for many configurations. What the evidence flags as the most inefficient are precisely the two extremes, fully centralized and fully decentralized. In the range between them lives a whole series of different opportunities.

Conclusion

So yes, there’s nothing wrong with what’s in Remote. The mistake is treating it as the only solution. I could hire isolated home-office individuals with no problem at all. It’s just that I still can’t picture how to make them grow, expose them to more than coding, and I could hardly delegate responsibility beyond the code. The great advantage of working in the services market is having access to more companies and more situations than any employee of a single company or a single product ever would. Remote and isolated, very few of those opportunities are left.

And again, there are exceptions: big names in the open source world who work as freelancers, alone, doing great, their reputation only climbing. I’ll fire back with a question: is that the rule or the exception? Exceptions exist, and if you can pull it off, being the exception is better. But evangelizing the exception’s path all the time is deeply irresponsible.

Working from home is an experience worth trying. It is by no means automatically better than working inside a group, even counting the “wasted time” on the commute, which, by the way, is a lousy excuse. A lot depends on whether your region has options. If they’re scarce, then remote becomes a good alternative. Just keep in mind there are always pros and cons.

Having lived on every side for a long time, I have news for you: programmers are terrible communicators. There’s a communication impedance that is turning into a serious disability. Inside programming communities the impression is that code is the only universal language.

But “show me the code” isn’t everything. Some time ago I answered on Quora that the hardest thing for every Software Engineer to understand is that 90% of a project’s problems aren’t solved with code.

Without wanting to generalize, just to illustrate: in the open source world it gives the impression that it’s the opposite. But note that the vast majority make small, sporadic contributions, and even those who take part more actively still live a fragmented experience. The software is ready only when it’s ready. And in the end, the vast majority of open source projects fail.

For every jQuery that makes it, dozens of other JavaScript libraries never get recognized, even with some technically better aspects. The big, best-coordinated ones, with brute force and contributors to spare, tend to fare better. But brute force only looks like efficiency. And the ones that grow show a very different organization, with release dates and feature roadmaps, converging toward what we know as real “projects.”

In the real world, time is short, people are few, the direct risks are much greater, and we want more control over the results. I won’t get into the merits of the best ways to do it, but deep down, in the real world, communication is the difference between failure and success.

Informing Isn’t Communicating!

The first thing to understand is simple: just because the information “exists,” or you dropped it somewhere shared, that doesn’t mean you communicated.

Communication has 4 ends: the communicator, the recipient, the message, and the medium of transmission. Programmers usually take on only 2, the communicator (themselves) and the message, and ignore the rest. Let’s define this better:

"Communication only happens when the recipient receives and understands the message. If that didn't happen, no communication existed."

Let’s go down a level and speak “geek”: there’s a client, a server, a protocol, and a medium of transmission. If you packaged the message according to the protocol, opened the connection to the server, and tried to send it, but the transmission never finished and came back with an error, we know communication didn’t happen.

In the TCP/IP world, first we send a SYN, which initiates communication. We get back a SYN-ACK, the server’s acknowledgement that it received the SYN, and we send an ACK to signal the connection is established. With this handshake, we manage to sequence the sending and receiving of packets and guarantee that everything sent was received in full.

In this metaphor, I’d say most programmers understand UDP better. They fire off datagrams of information and don’t worry whether the recipient got all the packets, they just keep sending. It really gives the impression that programmers think in UDP, just look:

• they don’t want to wait for a handshake to make sure the connection was established
• they send small packets of fragmented information, little protocol overhead
• TCP worries about congestion control and does throttling, UDP keeps sending even if the router drops the packets
• if a packet is lost, UDP doesn’t bother resending
• it figures broadcast and multicast look more efficient

It works fine for communicating to large groups, in broadcast, where it’s enough for a percentage to get the message. I’d say UDP works reasonably well in the fragmented open source world. But in a world where establishing a connection and guaranteeing delivery of the message matters, we go with TCP.

TCP works because, even with a bad connection, even with a half-baked server, you control the data stream and make sure everything arrived, in the correct sequence, with 100% of what was sent received. In UDP, if the medium is bad, if the server gets corrupted information, it doesn’t care and keeps sending.

Both protocols are useful. But if we need to be sure the information was received correctly and in full, we need TCP. In the open source world, using UDP to communicate, cut latency, and be more “efficient” is fine. Outside the open source world, and that goes far beyond software, we need to be more TCP. The advantages of TCP?

• making sure the connection was established before sending information
• guaranteeing the order of the information, rearranging packets if necessary
• moderating the transmission speed so as not to flood the other side
• guarantee of message delivery, not just transmission
• error checking, to make sure the information wasn’t corrupted
• “acknowledgment,” making sure the other side received and understood the information

See the difference? It looks like it takes longer, but it’s the old story: delivering fast and then having to redeliver several times ends up slower than making sure the message got through the first time. It’s like writing code without tests, it looks faster, but then come the consequences.

So, programmers, adjust your protocols. Be more TCP than UDP.

Alex Payne was one of the earliest engineers at Twitter. I know him from Scala and his posts on NoSQL and other tech topics. Beyond being a programmer and a book author, he’s a seasoned startup investor.

His view on startups lines up with mine. I recommend watching the talk, which grew out of a post on his blog with the same title as this article. I decided to translate that post into Portuguese because Brazilians need to hear more of the other side of the coin.

From here on, these are Alex’s words:

I regularly receive emails from young people, usually those interested in programming, who are trying to make decisions about school and/or their professional futures. This post is for those young people.

If you’re in your late teens or early 20s, you’ve grown up in a world that idealized startups, their founders, and the people who work at them.

If you’re in school, you may have felt pressure or have been encouraged to drop out and join or start your own company. If you’re already out in the working world, you may feel that your non-startup job is somehow inadequate, or that you’re missing out on valuable experience and potential wealth.

The generation you grew up in has, in recent years, teetered on the brink of becoming “lost.” Jobs are scarce, entering a university offers no guarantee of employment. Big, old corporations are no longer a guarantee of safe harbor for building a career. Startups appear, through the lens of the media, as the only sign of life in a dying world. I understand the appeal.

Everyone’s background is different, and your choices are only yours. That said, you’re not making decisions in a vacuum. Here are some things to consider that, in my experience, you’re less likely to hear about if you’re working in startups.

A startup is only a means to an end.

I recently interviewed a young guy. I asked him where he saw himself in four years. “Running my own company,” he said without hesitation. I asked him why. “Because entrepreneurship is in my blood,” he answered. There was no mention of what his hypothetical company would do, what problems he would solve for people. His goal was a company just for the sake of having a company. That’s what he studied for, after all.

People are satisfied in their jobs when they operate with a sense of purpose. So much of our understanding of the psychology of success revolves around goals and keeping those goals top of mind: visualizing the moment of achievement, tracking progress, having others hold us accountable to reach them. Goals shape our individual futures.

Maybe a startup is the best way to reach that goal, and maybe it isn’t. If the goal of the young guy described above is to own a business — any business! — then maybe a startup really is the best path. For others, however, I always wonder if they’re adapting their goals into the shape of a startup because that’s the most applauded, admired, and easily understood (if not easily achieved) approach.

Maybe the best way to reach your goal is starting a non-profit organization or going into politics. Maybe it’s doing research at a university or making art. Maybe the answer is joining a large, stable company with formidable resources you can leverage to reach your goal. Maybe your goal is best reached by building a stable, pressure-free career that leaves enough time for your family, friends, community, and self-improvement.

A startup is only a means to an end. Consider the end, and try not to celebrate the means. What do you care about? Who do you want to help? Does a startup make it easier or harder to reach this goal? Where will this leave you when your goal is reached? Where will it leave you if it isn’t?

A job at a startup is the new office job. Startup culture is the new corporate culture.

Startups are portrayed as being exciting, risky, and even subversive alternatives to traditional corporate employment. Startups are seen as freer, more open, more flexible. Some companies really do start like that, but some interviews at late-stage startups make it clear how fast they ossify into structures that resemble the organizations that came before them.

Just as in the first dot-com bubble, there’s currently a proliferation of startups, incubators, accelerators, angel investors, and so on. In order for the “startup community” to replicate itself, nanobot-style, the mechanics of “doing a startup” have been reduced to an easily transportable sequence of actions accompanied by a shared set of values, norms, and language. As a result, the culture of most startups is uniform, even in style of dress and accessories that help “startup guys” — and they’re mostly “the” guys — stay with their herd (so they’re not preyed on by cougars).

Business school graduates like the young guy I interviewed are going straight from university to startups, and that’s if they even finish school. Business graduates, traditionally risk-averse, now say they don’t want to work for big companies. But startups are the new big companies. They are, as I’ll describe below, the office cubicles of a distributed workforce aggregated by venture capitalists and their associated institutions.

There’s nothing inherently wrong with an office job. Just understand what you’re joining. When the company-supplied beer kegs run dry, when the free snacks are making you fat, and playing Xbox in the chill room isn’t as fun anymore, what then? When you find out you now report to a politicking middle manager and not the inspiring CEO who interviewed you, will you still want to be there? Is it an environment with enough toys and novelties to sustain you? When every place you consider working looks more or less the same, how long does the novelty last?

Startups have been systematized, mythologized, culturally and socially de-risked; reduced to formulas and recipes. And yet, there is no sustainable formula for creativity and rebellion. When we try to industrialize innovation, we tear out exactly what we’re trying to cultivate: the creative destruction that keeps the fire of capitalism burning.

Startups are part of the system, not a rebel wrench in the gears.

Funding for startups — that is, the money that pays your salaries — comes from somewhere. Wealthy individuals and institutions invest in startups like any other asset class. The futurist Bruce Sterling recently joked that “startups are full of young people working hard to make other people rich — Baby Boomer financiers, mostly.” Even though this may be a generalist and cynical statement, it’s by no means untrue.

In broad strokes, and excluding areas like biotech, venture-backed startups are a machine where relatively small amounts of capital are inserted on one side and, ideally, a lot comes out the other side. (In reality this machine seems to not work anymore, although the effectiveness of VC as an asset class and the VCs themselves is open to discussion). The salient point: what’s in the middle of the machine is you. You make it run.

The machine isn’t interested in you. In fact, the machine is designed with the understanding that most startups will fail, or at most offer mediocre returns to investors. Most companies in many VC portfolios are recognized as straw men. One or two “10x” companies are what give value to the portfolio. In the best case, founders of failing startups get another push at the slot machine. In the worst case, their failures lead them to despair.

There’s nothing inherently disruptive about a venture-backed startup. The startup system is just another system; an alternative to the corporate ladder but with as many rungs. Some startups may end up dramatically reshaping the market, but so can any other operator already in the game or active regulator.

The now perennial celebration of startup-driven disruption raises the question: if we accept that disruption is indeed happening, are we better off in the resulting disrupted market? Did we solve a problem, or did we just move the problem around? Are we creating value while increasing fairness and equality, creating positive change that will last? Or did we just make one group of rich people a little richer at the cost of another group of rich people? Are we creating a better future, or just reshuffling the present?

Startups have an ongoing interpersonal cost.

No startup story is complete without a scene or two of macho heroes: nights spent programming to exhaustion, weeks away from home trying to raise money in humiliating pitch after humiliating pitch. Startups appeal to a desire for daring that is lost in many forms of modern work, and we hear stories of the rewards waiting when personal lives are sacrificed on the altar of the launch schedule.

Less often we hear about the damage startups do to people’s lives. In extreme cases, like with the entrepreneur whose story of failure and suicide is linked above, the “community” may take a day or two to reflect and lament in blogs and tweets. Then they’re back to “the grind,” and more importantly, making a public show of how hard you’re working to satisfy the investors and the intimidating competition.

I’ve seen firsthand the damage startups can do to relationships. I’ve seen marriages and friendships destroyed, I’ve seen children and partners being sidelined, and I’ve failed those in my life in every way when work came first. I would listen as people who are the picture of a successful startup — visible in the press and social media, leading conferences, eternally founding and exiting — confided their total loneliness despite seemingly being the social center of the entrepreneurial community.

When you’re young, relationships seem like a renewable resource. Friendships exist in abundance and come easily. Just leaving home and into the world, you’re eager to escape the constant presence of family. Being pulled into work makes you feel important, independent, an adult. The work itself provides a new community and new friendships, and the bonds formed during intense collaborative work are strong.

I made many friends through work at early-stage companies. Ironically, these relationships are easier to maintain and enjoy when I’m not working at a startup.

Parting Thoughts.

I’ve worked in startups for half my life now. This work has brought me financial freedom, and I’ve put money I earned at a startup into other startups. If there is, as I’ve argued above, a modern “startup system,” I’m part of it.

I won’t mince words: I am deeply skeptical of this system. I’m skeptical of this system’s slavery, self-congratulatory fetishization of “disruption,” while at the same time becoming so obviously the kind of impassive institution it wants to replace. I’m skeptical of the short-term vision of the startup community. And I’m particularly skeptical of its disregard for the lives of the people who participate in it and the lives of those who live in the world that startups seek to reshape. Let’s not even start to discuss the collusion, cartelization, and other market corruption activities that are so common in the VC world. The point being: it’s a bad game, and a fraudulent game.

And yet. There are startups I wouldn’t want to see disappear. There are people working at and founding these startups who are good, kind, with balanced personal and professional lives, concerned about the impact of their work. Just as we throw slander and accusations of corruption at other systems like politics, mass media, entertainment, and professional sports, we must also admire those who operate ethically and effectively in them. We should celebrate even more those who pioneer new and alternative systems, because they work in the shadows of the community that has a constant hand on the crank of the publicity machine.

Now, you could say that I’m laying too much responsibility at the feet of the startup world. Although this system spreads every day over itself as the savior of everything, from capitalism to culture, of course we can accept that business is business and ideals are better left at home. As a VC from a top firm on Sand Hill Road told me during a pitch many years ago when I was describing a conceptual feature in Simple that would make it easier for users to more easily and regularly donate a portion of their savings to charity, “let’s not waste time on that stuff, we’re here to make money.”

You may be able to stomach that conduct, but I hope your idealism hasn’t been worn down while still so young. I hope you want your work to have meaning, purpose, and value no matter what form that work takes. More than that, I hope you want your life to be defined by more than your work.

Young programmer, I urge you to consider both sides of the startup coin. There are so many ways to leave a mark on the world.

A Note about Feedback

If you are part of the audience of this post, I’d love to hear your feedback and answer your questions, preferably by email. My address is easy to find on this site.

If you are not part of the audience of this post and are really, really angry that a stranger on the Internet has a different opinion from yours, I encourage you to direct your energy into an alternative argument that someone young (or, really, anyone at a career transition point) could benefit from reading. They are your future employees, coworkers, or founders. They are the ones you need to convince, not me.

— May 23, 2013

I’m a software engineer and, after twenty years across different companies, markets, and teams, I see a pattern. Practically every engineer I’ve met starts with the premise that “code” is the goal and the solution to every problem.

The truth is that, in the market at large, software problems aren’t solved with software. I’m not talking about the exceptional cases of research and development or academia. This is the first and hardest thing every engineer struggles to understand, and fights against.

Linda Vasquez: I know he made you a promise, but circumstances have changed.

Francis Underwood: The nature of promises, Linda, is that they remain immune to changing circumstances.

– House of Cards

One thing a lot of people cite as the hardest is “estimating,” because you so rarely land on the right estimate. And that’s where the problem lives: the phrase itself is confusing.

Estimates, by definition, will never be “correct.” If they were, we’d call them “predictions,” and they’re two separate words for exactly that reason. In a prediction the variables are known and fixed, the path is predictable and automatic. That’s the lab scenario: “given ideal conditions of temperature and pressure, in a vacuum, with zero friction, a toy car at a constant speed of 10 meters per second, for 10 seconds, travels 100 meters.” And estimates?

Outside the lab, we have estimates, and estimates are PROMISES.

Promises are made to be kept. A promise doesn’t resolve itself. You have to make a deliberate effort to reach it and keep your word. With estimates it’s the same: you estimate and then you work hard to deliver what you promised.

“But the manager/client/investor/boss keeps pressuring me to add more things, make changes all the time, breaking my concentration with irrelevant problems all day long.”

Yes, they do this, and they’ll keep doing it, yesterday, today, and always. The most common reaction is to get defensive. To avoid committing, people decide to give no estimate at all, or throw out a number so out of proportion that any “extra” is sure to fit. That’s a terrible default.

Say you promise your daughter you’ll be at her school presentation. You blow it and show up two hours after the whole thing is over. That failure is yours, and yours alone.

It wasn’t traffic, it wasn’t the surprise meetings, it wasn’t the weather. You made the promise and didn’t prepare for the bumps along the road: leaving earlier, getting ahead of the problems, building in slack for the unexpected. You left everything for the last hour, walked out at the last minute, and, of course, shit happens.

With estimates it’s the same. You said a number with no commitment, no sense of responsibility, and did nothing to get there beyond sitting down and writing code. You never went digging to explain the problems.

Saying it once, your way, doesn’t mean the other end understood. Whoever starts the communication is responsible for finding a way to get the message across; without that, communication didn’t happen. To communicate is to be understood, and being understood is the responsibility of the person talking.

So you failed at communicating, at managing your own time, at helping your peers with the problems. All of it was your responsibility. Writing code was the smallest part.

Having a sense of responsibility is exactly the second hardest thing every engineer faces. If the starting premise is that they only answer for “writing code,” they don’t see the broken communication as their own failure. So they rarely own the outcome: it’s much easier to blame everything else. And that comes straight from the first difficulty, the wrong premise that your only goal in life is to write code and that every problem is solved with code.

This doesn’t apply to software alone. It applies to the musician, the cook, the builder. As a working professional, sure, you’re expected to be great at your craft. But that’s the bare minimum of the foundation, and there’s nothing exceptional about being technically good, however impressive the skill may look.

There’s no point writing the most elegant, perfect code if it solves the wrong problem. It’s like composing the most perfect Beethoven-style classical piece for a job that called for music at a kids’ birthday party. So one of two things: either you don’t take the kids’ party, or you write the best pop tune you can. If you took it and stayed, either you deliver with exceptional quality, within expectations, or you own the fact that you can’t and step aside, without getting in the way of whoever can solve what you couldn’t.

Anyone offering a service needs to understand one thing: the goal is to implement the best possible solution, but for the right set of problems. And the hardest part is finding that right set. Clients come to professionals precisely because they don’t know either. It’s on us to help find those problems, to judge whether keeping the promise is within our reach, and then to keep it, managing every obstacle that shows up along the way.

It sounds simple put like this, but even experienced engineers fail to grasp this truth, and plenty get away with breaking promises using tricks to hide the hole they dug.

So learn the first and hardest truth in the world: software is normally not solved with software, it’s solved with human capabilities. On a Pareto distribution, I’d say 80% of every software problem only gets solved when you invest the remaining 20% in communication, articulation, clear and rational thinking, breaking ambiguities, negotiation, and commitment.

Given all that, it can look easier to never promise anything. Except that never promising means never committing, and never committing means never being a professional. That’s exactly what separates the amateur or hobbyist from the professional: making promises and working to keep them. It also happens that you don’t hold up your side because it depended on the client, the boss, or whoever holding up their side first. A mutual exchange of promises is the whole reason there’s a referee called Justice, and the instrument that records those two promises has a name: a contract.

All that said, can you keep every promise? No, unfortunately you can’t. But it’s our responsibility as professionals to always chase that ideal, instead of inventing ways to dodge it.

I’ve said more about what I consider a professional to be in a 2011 post, "[Off-Topic] Opinions, Truths, Democracy, and Ethics".

Taking to the streets isn’t the only solution.

"Never in the history of the world has anyone ever achieved anything good and valuable by means of prayers and supplications" – J.P. Morgan

I don’t want to judge or analyze the #vemprarua (“come to the streets”) movements that took over the country’s streets in the recent past. It’s a tangle I’ll leave for political scientists and historians to untangle. What I want to elaborate on is a mindset that comes out of this kind of movement and shows up in our day-to-day: “claiming,” the act of “complaining, demanding.”

It’s very common for this new generation to fall into the trap of thinking that demanding is the best solution to problems. They’re wrong. Barring extreme cases, that’s always the worst possible solution. In the daily life of the common man, demanding is just a declaration of your own incompetence.

Let’s consider our tech market in general:

• Demanding better working conditions: nobody works anymore in dirty, smoky factories, alongside rats and sewage. Come on, nobody even works 8 hours a day nonstop, at most 4 hours stretched over 8.
• Demanding better salaries: it’s a free market, with dozens of tech companies of all sizes and categories. Mobility is easy. Of course, only someone with the ability to do it manages to move from one company to another for more money. Whoever stays put, unhappy, and only knows how to “demand” a raise is already showing their low character.
• Demanding investments: it seems startup ’entrepreneurs’ today are turning into ‘professional beggars,’ convinced they can only move forward once an investor hands them money.

The “demanding” mindset leads to another one, the “cheap complainer,” the person who blames everyone but themselves.

• “What they’re asking is impossible to do in this time and cost.” The thinking behind it: “I can’t picture a way, so it must be impossible.”
• “The product’s users are stupid, the problem isn’t the product.” The thinking: “if I made it, it can only be good; if they’re complaining, they’re the stupid ones.”
• “The market is unfair: I know more and earn less than I should.” The thinking: “I know I’m really good, so why don’t they pay me what I want?”
• “They only criticize me, and what about the other guy who also didn’t do it?” Nobody likes being criticized, but without criticism there’s no progress. Worse still when the first reaction to criticism is to compare it with someone else’s mistake or to justify it by blaming others. That profile will never go far. Praise doesn’t help anyone evolve, cheap praise least of all.

The “Me me me” Generation is the most sensitive I’ve ever seen. It should be called the “Porcelain Generation,” because it breaks way too easily.

In the Industrial Revolution people were literally hard as iron. There was no option: many died in the factories, and the concept of “working conditions” didn’t even exist. In the agricultural era, people worked from sunrise to sunset, earning very little and carrying tons on their backs.

Now this digital era has a stereotypically Emo resilience (nothing to do with the origins of hardcore punk): scratch a fingernail and they panic. Adolescence is being stretched, and adulthood only shows up after 30 (back in the day, 16 was a good age to take on an adult role).

That should actually be a good thing, because it means we’ve raised comfort to a level never seen in millennia of human history. But there’s a side effect: the new generation grew up without understanding how hard it was to get here.

All of this can lead to a question: “so I’m supposed to swallow everything I don’t like?” Not at all. And here’s a hook back to my previous article “Constraints are Liberating: less is more”.

Always assume this premise: nobody is ever going to give you what you want or need, much less anything beyond that. If you haven’t earned it, you don’t deserve what you’re asking for, and nobody has any obligation even to listen to what you have to say. It’s on you, and only you, to solve your own problem, with your own sweat and your own tears.

To me, the difference between a child and an adult is simple: an adult solves their own problems with their own hands and never expects them to be solved for free. And “solving” means actually solving, without blaming others, without demanding, without sweeping the problem under the rug.

And when the problem looks “impossible” is exactly when you get the best chance to innovate. Innovation comes precisely out of an impossible situation. A thing is impossible when you can’t pull it off with what we know today. You can only solve it down a different path, one nobody knows yet.

The teenagers graduating from colleges today see this trendy “Startup” wave and want to be “entrepreneurs.” All they learn to do is put together PowerPoints for Demo Days. They believe their “education” (which is thin, no matter the MBA or PhD) and their “idea” are enough to crown themselves “entrepreneurs.” That’s little, extremely little.

An “entrepreneur” who takes low risk and makes low sacrifice is just an average employee with a fancy title. An “idea” and a possible investment solve very little.

First, go work in a real industry to learn how it works and, who knows, find a solution nobody has tried yet. Because here’s another truth: whatever idea you have, someone has probably had it before and already tried it in all sorts of ways. The odds of you having a truly original idea are low.

Only when you land in an impossible situation, where everything has already been tried, does the chance to try something new and maybe innovative show up. As you try to solve it, you might end up finding a solution that already existed and discover that your “impossible” was just not knowing what was already known. Then you move on to the next problem.

I was watching the History Channel series “The Men Who Built America”, which shows, in a romanticized way, part of the story of how the United States conquered and earned its place as the biggest economic power in the world. The story starts like ours: nobody gave them anything, everything had to be earned. It has some good examples I like to cite.

• It was impossible to transport goods across the entire country by horse or even by ship; it became more and more necessary to find ways to shorten that time. It was the railroads of Vanderbilt that connected all the states of the country.
• It was impossible to have a corporation as large and massive as Standard Oil once was, but Rockefeller innovated what we know today as corporate structures, many of his practices later deemed illegal. If you’ve ever filled your tank at an Esso station here in Brazil, it’s worth remembering where it all started.
• It was impossible to cross the great Mississippi River with an iron bridge. Connecting the East and West of the country seemed impossible. It took an Andrew Carnegie to execute the idea of an affordable steel industry at large scale to solve this problem. Carnegie Steel was formed, which would later become US Steel.
• It was impossible to have electricity distributed to every home in the country. It literally took the “blood” of geniuses like Edison, Tesla, Westinghouse, and Morgan to reach this goal. Today we don’t even think about it, because everyone assumes electricity is something “natural.” It wasn’t.
• It was impossible to improve the brutal working conditions in factories and have productivity at the same time. Henry Ford changed that with the refinement of his production line. By the way, remember the model that made him famous was the Ford Model T; to get to “T” he started at model “A.”

These and other “self-made men” changed the world one way only: by solving one problem at a time, without claiming, complaining, or demanding. And the more “impossible” the problem was, the more “revolutionary” the solution turned out to be. That’s how great entrepreneurs are made: solving their own problems with their own hands.

The opening quote of the article sums up its content, and the next one defines it:

"Vision without execution is hallucination" – Thomas Edison

In 2007 I wrote two articles on “consultancies,” A Vent and A Vent II. They’re worth a read to understand the context. I like to reread my stuff to see whether I’d still write the same thing today.

The first is a set of tips for a consultant to improve themselves. In the second I describe the greatest sin of a consultancy. I wrote both when I already had a few years at companies in different industries, the most recent being several years at a consultancy.

The first article is very simple, and what I recommended back then is what I still recommend today: continuous improvement. Two points from the original text:

It's no use just changing jobs, for two reasons: a new project won't necessarily bring new things (the chances of being just another form are high). And leaving learning only for when you need it, on a project, is already too late. You'll be overtaken by others who know what you should have already known. It's a good programmer's obligation to know things before, not after: after a terrible quality product goes into production, the result will be bad both for your client and for your reputation.

Stop complaining. Complaining creates a negative mentality, irritates others, and doesn't lead to any solution. Complaining is just another excuse, a noise that hides the real problem. The problem is this: you're complaining about the job, about the project, about the boss, but in reality you'd like to be complaining about yourself. Complaining is just the externalization of the frustration of being what you are and not being able to be more. And that's not a physical inability, it's just mental laziness.

For me, the great advantage of working at a consultancy instead of staying at a single company? It’s being exposed to different projects, different companies, different people, and different ways of dealing with each type of problem.

Look at it this way: a consultant is seen as a “pariah.” A company’s employee, in particular, has no reason to like a consultant, because they’re usually called in to do the employee’s job, in less time, with better quality, and earning more. In practice, if the consultant succeeds it’s because the employees were doing a terrible job before. It’s not always like that, but that’s the general view.

From the consultant’s point of view, it’s a hard job. They have to step into a context the employee had months to absorb, figure out what needs to be done and why it hasn’t been, and produce more than everyone else with less authority and less knowledge. A consultant is effectively a mercenary: we’re called in for the work nobody else could pull off.

Note: anticipating the freedom to interpret the “mercenary” metaphor, let me clarify I mean “the one called in to solve the problem no one else could” and not “being paid to do whatever they’re asked, including the wrong thing.” With the metaphor clarified, let’s move on.

That’s what I like. And that’s why a good consultant can’t regress to the standard-employee mind, the same way a mercenary doesn’t compare themselves to the private soldier: they need to be the soldier and the general. When I was a consultant, what pleased me most was being aware of this position, walking into a client knowing I’d have to solve the problems the insiders wouldn’t.

It was feeling the pressure of walking the front line without knowing what I’d face in the middle of the jungle. Talking to the subordinates, to their bosses, to the surrounding departments, and mapping the terrain to find the best path through the minefields. Being able to disagree directly with the client and, at the same time, offer a better solution than anyone had thought of. That’s the exercise of every good consultant.

The second article, A Vent II, revolves around a problem I’ve seen at many small and medium consultancies: poor financial health. That’s “The” main problem:

When a consultancy shows signs of financial problems, it's the red signal: jump out as soon as possible. Don't think twice. If the client decides to throw a tantrum, if the client decides to delay the invoice, if the client decides to stall, none of that is the consultant's problem: that's exactly what we pay this insurance to the consultancy for — so that it places itself between the client and you. The consultant, correctly working the hours billed, has the right to receive on the dates in the relevant contracts.

A large consultancy, with an established name for at least a decade, can get a sale price (rate to the client) up to 5 times higher than the buy price (rate to the consultant), or more. But that’s the exception in most of the market. In my case, the maximum is 50% of the buy rate, and almost 2/3 of gross revenue goes to payroll.

That’s the reality of the services market. With a tight margin, not counting other operational costs and investments, commercial and financial control is fundamental. You know a consultancy is competent when you’ve never had to complain about your payment, in a sector where clients never pay on time.

There are several advantages to working alongside a good consultancy instead of going it alone as an autonomous worker or freelancer, and being paid on the right dates is one of the main ones. If payment comes in unstable, or turns into a stiff, the freelancer option gets attractive again. So when I decided to start my consultancy, this was one of the main concerns. The rule I never broke: everyone gets what’s in the contract, on the stipulated dates.

And after more than 1 year, one of the most unstable periods in a services company, that rule held intact.

But that’s not all a good consultancy offers. The word “consultancy” is a big umbrella, unfortunately distorted by misuse. I split the definition into at least three big niches.

The first is agencies. Here the consultancy is about marketing and advertising, at most, and the software part usually carries low value in the total budget, sometimes handed over more as a “freebie.” Execution is low quality because the pieces are volatile, temporary, and don’t need to last long. Anything different from that, done in agency style, rarely works well.

The second niche is the infamous software factories. In them, most people work as pure “procedural executors,” never quite reaching “consultant.” The fundamental trait is missing: direct contact between the programmer and the client.

The executor works inside a defined process, receives work orders, clocks a fixed number of hours, and their only task is to deliver what’s already been detailed, in fixed roles. There are variations, but in general the factory is driven by a process that tries to be deterministic. For that, the kinds of software tend to be limited: forms, registration screens, and form flows, especially company intranets or integrations with back office.

The third niche, “consultancies,” where “consultants” actually exist, is rare. The assumption is that the kind of professional at a consultancy is superior to the one at an agency or a factory.

To understand this niche, we need to see what the disadvantage of being a freelancer is. A freelancer has to be a mini-consultancy: doing their own personal marketing, cultivating relationships and a commercial network, negotiating rates, scopes, and deadlines, closing contracts (and most close them verbally, because they don’t know how contracts work), issuing invoices, billing, and so on. Oh, and in the middle of all that they still have to program.

Their compensation tends to be higher because of that overhead, but it’s precisely because of it that productivity and quality tend to drop. And when the overhead isn’t handled well, the result is low-trust deals closed verbally, the way you should never do it.

A good consultancy removes that overhead and does it in a superior way. It’s a service exchange, my ideal concept of “voluntary exchanges for mutual benefit”. The alternative to being at a consultancy is acting as a freelancer or becoming an employee at a company whose core business isn’t necessarily software. And here’s a parenthetical: even at a tech startup, I’d say the core business is rarely the software itself, reflect on that.

“Services” is a free market where exchanges are essentially voluntary: service in exchange for compensation, as it should be.

There are companies where software is the core business, like software consultancies. And others where it isn’t, like commerce companies, where software is accessory and not the main business. Or hosting companies, where the core is unquestionably infrastructure and operations.

That’s another thing I learned as a consultant: identifying the core business. If a company sees software as “profit,” that’s where it invests, that’s where the future is. If it sees software as “cost,” it tends not to invest, and to swap what it has for cheaper alternatives.

And that makes sense. Why invest in software at a company whose core is sales? Or finance? There, software and programmers are cost, like a Word or Excel license. If the goal is to grow professionally, look for companies where software is part of the core. If you want a quiet job, routine and few activities, accepting the invisible risk of going obsolete fast and being subject to cuts, look for companies where the core isn’t software.

Back to the difference with a freelancer: the consultant doesn’t have to worry about marketing, contract negotiation, legal, billing, cash flow, or HR. Like a good mercenary, they get a mission and carry it out. More than that, the consultancy closes projects that would never be within a freelancer’s reach, and offers a delivery security a freelancer can’t provide.

A good consultancy also doesn’t end the contract with the consultant just because a project wrapped up. That’s another freelancer pain point: when a project ends, a sales cycle begins that usually drags. A good project takes 1 to 2 months of negotiation to sign, from first contact through proposals and adjustments. The consultant doesn’t carry that weight; they just deliver with consistency and quality, while the consultancy handles the overhead of keeping a healthy pipeline of projects always coming in.

Now, the key point: “like a mercenary.” That’s the most undefined part of the model. I believe a good consultant doesn’t need an “operational boss,” the traditional “manager” who defines work orders, takes over communication with the client, does the internal politicking, and tells each “employee” what to do.

Of course there are senior and junior consultants, and juniors will always mirror and learn from the seniors, but that doesn’t make them “bosses.” A good consultant is like a good mercenary: either they know what needs to be done, or they figure out how to do it, the right way.

“Autonomy” is the buzzword everyone learned to repeat like a cuckoo clock. Everyone only remembers the “freedom” part of the word, and conveniently forgets the “responsibility” part.

“Oh, but I am responsible.” You aren’t. Your name isn’t on the company’s articles of incorporation. If the company takes a loss, goes under, or has to deal with its own debts, the one who pays is the partner, not the hired consultant. Legally, you’re never responsible, until you become a partner.

And that’s a real possibility for whoever turns into an excellent senior. At my company it exists, and it was recently exercised with the entry of 2 new partners.

If the consultancy gives you the “freedom” to run a project the way a consultant needs to, no intermediaries, no operational boss, no short leash, it’s because there’s far greater trust than any company would give an employee. If something goes wrong, the consultant has zero risk and the consultancy bears 100% of it.

That’s another crucial factor some don’t get. It’s like insurance: would you drive a new car with no coverage? The consultancy is the consultant’s insurance. There they train on projects where they technically have no “responsibility” and still gain knowledge, capability, and networking, at zero risk.

That’s what I liked most about the consultancy where I worked between 2002 and 2007. I came in as a junior programmer, practically a trainee, even though I already had at least 5 years of prior experience. It was all new, so it meant taking a few steps back to learn. And I learned.

On some projects the challenge was purely technical, building software on platforms, tools, or languages I’d never used. On others, it was coordinating the work with colleagues the best way possible. On others, it was talking to the client to find out what they needed and executing the best solution. In the end, the challenge turned into selling, convincing the client of the right solution.

I never held the title of “manager,” “pre-sales,” or “architect,” but I acted in all those roles, switching from project to project as the situation demanded. At one moment I was the only developer assigned for a short stretch to solve a technical problem nobody could. At another, I was the one putting together a team of 10 people, hiring and coordinating. In all of them I did what I knew I should do: solve problems. A consultant who creates problems has stopped being a consultant and become just another employee.

A consultant’s compensation is also different from an employee’s. Part of why employees grow more slowly is that their pay rises almost automatically, nearly independent of individual performance. Even the best-equipped companies, with formal reviews and all, end up at the mercy of the ones who, instead of working toward growth, work to find holes in the system and do less. Public-servant profile, pejoratively: automatic annual raises, scheduled title changes, a bad environment for anyone chasing growth.

A consultant, like a freelancer, grows by performance, by delivery, and by how much the clients themselves recognize they deserve more. I’ve seen plenty of excellent consultants who, on switching consultancies, took the client along because of their exceptional performance. Today I don’t see that anymore, just unethical ex-employees trying to negotiate with the consultancy’s client on the side, in talk only. And what good client falls for the sales pitch of an ex-employee who clearly doesn’t deliver results?

The biggest problem at a consultancy is when the consultant regresses to the standard-employee stage. The symptom: instead of chasing results, they chase excuses not to do the work as they should.

There’s a big difference between the one who complains and keeps delivering good, consistent results, which is what they committed to when signing the service contract with the consultancy, and the one who complains and delivers less and less at lower quality, already going against what was agreed when hired.

The clearest sign shows up in “unionization” movements (in quotes, pejoratively, because unionizing in a market that isn’t monopolized or cartelized makes no sense). It’s the one who produces little and starts stirring up the people around them to create “movements,” smoke screens to pull attention away from themselves. It’s the one who spreads slander, insult, and defamation about colleagues, clients, and the company they work for. Easy to spot: it’s always the one who wants to “speak for you, for the good of the group.”

Exactly because of this, every consultancy has a turnover rate higher than that of ordinary companies, and it needs to. It’s the sector’s dilemma: a services company holds its intellectual capital in its people. Letting go of an employee, much less a consultant, means losing an important asset of work and relationships.

That’s why, when a services company lets someone go, it’s a conscious decision, aimed at admitting a hiring mistake and taking a step back to take two forward right after. Part of this I described in the article Net Negative Producing Programmer.

The only dismissal that actually harms a company is the one that happens after there are already signs of financial weakness, in the form of delayed salaries. Either way, not everyone was born or wants to be a “consultant,” and some only find that out over time. It’s all a matter of perspective.

To start with, a good consultant speaks for themselves and doesn’t need intermediaries. And they should know that everyone knows everyone in this market, where reputation and credibility are currency. Just think: what company would hire someone who defames the places they passed through?

Sometimes the consultant doesn’t understand the advantages of their own position. More autonomy always comes with more responsibility, and more responsibility always brings more challenges and more difficulty. Everyone asks for “more challenges,” but few take them on when they show up and say “let me handle it.”

Many look for a job as an “employee,” in the sense of deferring responsibility (the famous “I just work here”). Technically there’s nothing wrong with that, not everyone was born to be a problem solver. Some prefer to work on one thing, to be around a smaller group of people for longer, to limit their perspectives because they have no interest in cultivating (and maintaining, since knowing isn’t enough) a large network.

What many are after is at least a “false illusion” of “stability,” a word that lost its meaning in the 90s, after outsourcing and globalization. Or a “false illusion” of “purpose,” signing on to an “idea.”

I could write a whole article about “signing on to ideas or ideologies,” but I’ll sum it up like this: mostly it’s a false expectation, from a lack of experience and exposure to a broader perspective. As I said, the advantage of a consultancy is giving you that time of exposure to different ideas, people, situations, and perspectives, which trims the rough edges off illusions and teaches you how the real world works.

The thing is, there’s that annoying factor called “time.” Most young people today have less and less patience and are more impatient for instant results than I was back in my day. The irony is that my seniors used to call me impatient, and even so, for me it was always natural to take one step back to walk two forward.

On those who want to open their own business, many justify themselves with lines like “I’m going to work for me and not for others.” That line is a huge false premise. In practice you “never” worked “for others.” Have you ever worked for free, with no compensation at all?

If you got paid, then by definition you worked for yourself, trading your capacity and the quality of your service for money. When you open your own company, you’ll make the same trade again. The earlier and the more inexperienced you do it, the proportionally greater the chance it won’t work out. It shouldn’t be a hard line to grasp, but understanding comes with knowledge and experience, and not with recklessness.

And what defines a “consultancy” for me? I like to think of it, philosophically, as a “meta-company”: a company that carries parts of other companies and needs to be better than them. It doesn’t mean it always will be better, but that’s the “mission” to be pursued without letup. A career in general is exactly that, and being a consultant is taking on that mission more explicitly.

In the end, my goal was always not to repeat what I described in my 2007 Vent: to build a financially healthy company, win clients and close contracts a freelancer couldn’t, with security for both sides. To create a routine that doesn’t require working more than 8 hours a day and 5 days a week. And to build teams as cells exclusive to each client, without the intermediation of an “operational boss,” giving each consultant the chance to learn all the non-technical functions I mentioned above.

2012 was a year of learning and experimentation, with far more problems than I could foresee. Fortunately, my years in consulting gave me the foundation to close out every one of them. Honestly, I can’t picture myself in 2002, when I started in consulting, handling today’s situations and making the same hard decisions.

If I had opened a consultancy in 2002, or any company, I would have closed it, unless I’d had “luck.” And betting on games of chance isn’t what makes a good consultant.

Happy New Year! See you in 2013.

Everyone knows I steer clear of self-help, but every now and then I figure a little of it doesn’t hurt ;-) One thing I always tell just about everyone who has worked with me in recent years: a job isn’t for life. You never know where you’ll be tomorrow, and you should never assume you’ll be in the same place.

While you’re at a job, you should absolutely do everything you can to deliver your best work, even when that often means pulling all-nighters, putting in extra hours, and carrying heavy responsibilities. Up to the limit of what’s tolerable and stops short of abuse.

And unless you’re the company owner, a partner, or a sizable shareholder, that limit must be short. Whether you make R$40k or R$250k a year makes no difference. The result is always the same: the longer you stay in the same place, doing the same thing, the less you’re worth. There’s only one person you owe blind loyalty to: yourself.

The most important part: what’s your goal? Why are you doing what you’re doing? Does what you do today move you toward where you want to go? If it doesn’t, why keep doing it? “But I don’t have any particular goal…” Then find one.

Everyone already knows I’m a strong proponent against certifications, specifically in IT. The intention behind them is good, but the practical effect ends up more harmful than the benefits. As they say, “the road to hell is paved with good intentions.”

I’d go further and put an umbrella term over it: I’m against “Credentials” in general, especially when used out of context. And I like to argue about argumentation itself. I’ve been mentioning fallacies whenever I can for a long time. I’m far from a complete grasp of the subject, but I keep trying to expand that understanding, and I think everyone should.

A simple example. I love the work of a Martin Fowler, or a Robert Martin. I find their insights very valuable and their recommendations excellent, people who genuinely work hard to be above average. The problem is they’re also human beings and, as such, they have flaws. That’s an indisputable fact we need to accept in every argument. Just because an Uncle Bob said something, that doesn’t automatically make it true.

It should be obvious, but plenty of people get “dazzled” by celebrities. They literally turn into “cheerleaders.” Because the guy worked at some renowned company, or wrote a book, or simply because he’s a foreigner, anything he says takes on the weight of truth. And that’s a huge danger.

Everything the big names say has to go through the same scrutiny as what someone with no renown says. No exceptions. I repeat a lot of what a Fowler says because it holds up in practice: you can test it, discuss it, and above all refine and evolve it. His name is not what gives the argument its weight.

This is the appeal to authority fallacy: because A said B, and because A is considered an authority, therefore B is true. Pay attention, because we use this every single day. This one and a dozen other fallacies (see the list below) show up daily, and we fall for them all the time.

The opposite holds too. Just because Philippe Kruchten helped create RUP doesn’t mean he’s bad (kidding, the guy is very good). This is another thing that bugs me a lot: attacking a technology or a practice by attacking whoever created it. Something like “Rails is bad because David is arrogant.” That’s the fallacy known as the Straw Man, which in more general form means bringing up an irrelevant subject to pull attention away from the main point.

Both cases are bad. It also feeds the tendency to ignore whoever has no renown. Your most experienced employee, the one who actually understands the problem, sometimes gets ignored because someone with more renown, but completely out of context, dropped a few “truths.” Now that “truth” is law. No further questions.

And the reverse exists too: believing your most senior employee just because he’s the most senior. Neither of those is a good justification. The person is secondary. What counts is the argument, as long as it follows the scientific method.

The fact is most of us are lazy about thinking. Plain, simple laziness. On top of that, we were raised with authority figures who would always be more right than we are, something I’d chalk up to low self-esteem. So when someone in a position of authority shows up, the tendency is to accept what comes from them, especially if we’re already comfortable with that understanding. It’s the old problem of leaving the comfort zone.

Most people weren’t trained for change, they were trained for stability. That’s why anything different gets side-eyed. Most people only hear what they want to hear and only see what they want to see. Nobody from outside can easily change that in another person, which is pretty sad.

A few Wikipedia articles on argumentation:

• Argument
• Argumentation Theory
• Burden of Proof
• List of Fallacies

A person who doesn’t like to argue, by definition, cannot be a decision-maker. Many use other people’s credibility inappropriately (“because so-and-so said, out of context, but said…”). Worse still is when a decision is made by shouting, by force of the job title. That’s the attitude of someone with a clear inability to argue and, therefore, to understand the subject.

Of course, on many occasions we’re forced to decide “by instinct.” If we spent the whole day arguing every tiny decision, we’d get nothing done. Imagine debating whether to wear the red shirt or the yellow one, and why. I’m not talking about micro-argumentation, which, like micromanagement, doesn’t work.

But decisions that involve people and diverging points of view deserve more care. If, even after arguing, you still can’t draw a logical conclusion from any of the premises, in the end it’s instinct that guides the solution. Argumentation sits in the humanities: it uses scientific principles to build better arguments, without the precision of an exact science.

Still on fallacies, plenty of people believe in the “dictatorship of the majority,” in “if the majority said it’s true, then it must be.” One form of this fallacy is the argumentum ad populum, that sneaky way of opening a sentence with “Everyone knows that…” I always say I admire the Founding Fathers of America for having insights advanced for their time that people to this day don’t quite understand. Quoting Thomas Jefferson:

All, too, will bear in mind this sacred principle, that though the will of the majority is in all cases to prevail, that will, to be rightful, must be reasonable; that the minority possess their equal rights, which equal laws must protect, and to violate would be oppression.

So it isn’t that “the majority wins in all cases,” but that “the majority wins in the cases that don’t violate the rights of the minority.” The difference is subtle. Picture the majority deciding your property should be taken, and concluding that, being the majority, it’s in the right. Every individual has a right to their own property, and government exists to protect it. The majority’s will to take someone’s property is voided because a fundamental right is being violated. That, by definition, is called oppression. Democracy is something else.

Thinking is hard. It takes study, takes culture, takes practice. Thinking hard isn’t something most “busy” people feel like doing. Most prefer ready-made, canned answers, or picking something fast “by instinct.”

There’s also “I chose right before, so I’ll always choose right” or “it worked somewhere before, so it works here too.” That’s the good old Post hoc ergo propter hoc fallacy.

“Post hoc ergo propter hoc” is exactly why self-help books, magical methodologies, “advanced” recipes, and every kind of canned procedure sell so well. They take the work of thinking off people’s hands and hand them ready-made answers, “that already worked in dozens of places,” or something along those lines.

Some of these recipes, after prudent research and experimentation, really are good. Most, though, remind me of an allegory about medicine. Imagine if every doctor acted this way. You walk into the office and say:

• Doctor, I’m in a lot of pain.
• My son, take this medicine every day and the pain goes away. You can leave.
• But doctor, aren’t you even going to examine me, diagnose me?
• What for? I already gave this medicine to the last 3 patients and they all got better. Why would it be different with you?

Funny? It shouldn’t be. Look back at the decisions you make, or that the people around you make, and you’ll notice they look a lot like that allegory. And like most of the fallacious arguments I mentioned in this article. I catch myself falling for that kind of trick many times. Even the most vigilant person falls. Argumentation is an art. So is understanding.

So the only thing to do is what I say all the time: Be Skeptical. Always question the Status Quo.

Update 08/26/2009: Excellent historical analysis of a good legislative proposal that had already been rejected once, via Gizmodo

Update: 08/25/2009: I just added a long argumentative text about the Law in this article.

It’s in the news:

The proposal that regulates the practice of the systems analyst profession was approved this Wednesday, the 19th, by the Senate’s Committee on Constitution, Justice and Citizenship (CCJ). The bill (PLS 607/07), authored by Senator Expedito Júnior, now goes to the Committee on Social Affairs (CAS) for a terminal decision.

Under the substitute bill previously approved by the Committee on Science, Technology, Innovation, Communication and Information Technology (CCT) and adopted by the CCJ rapporteur, Senator Marconi Perillo, only professionals with a university degree in systems analysis, computer science or data processing will be allowed to practice the systems analyst profession.

I recommend everyone reread my article from last year on this topic. This law is a complete farce, created by this Expedito Júnior and embraced by this Marconi Perillo.

The Text of the Proposed Law

I decided to go through the text more carefully. The original proposal was the failed Bill No. 1,947 of 2003 by Eduardo Paes, thankfully shelved. Not satisfied, Expedito Júnior introduced the disastrous Bill No. 607 of 2007. I recommend reading the original version first, available as a PDF at this link.

The first review was by the Committee on Science, Technology, Innovation, Communication and Information Technology, published on 03/05/2008. It isn’t entirely bad, but it has several flawed points of interpretation, and I’d rather not decide whether that comes down to bad faith or laziness. The report opens by citing the SBC, the Brazilian Computing Society:

According to information disclosed by the SBC itself, what matters in regulating the profession is the observance of certain principles such as the free exercise of activities related to the information technology field. Thus, no professional council should create any obstacle or restriction to the above principle, and the field should be self-regulated.

That’s correct, and I think everyone in the field agrees with it. But the very next paragraph gets the interpretation wrong, obviously written by someone from outside the field:

In this case, that is not the issue, because art. 2 establishes that professionals “may” practice the profession of Systems Analyst, Computer Science or Data Processing, which greatly expands the possibilities for professional classification, covering practically all university courses in the information technology field.

To be clear, art. 2 states the following:

Art. 2. The following may practice the profession of Systems Analyst in the country:

I – holders of a university degree in Systems Analysis, Computer Science or Data Processing, issued by official or accredited schools;

II – graduates of foreign schools recognized by the laws of their country who have had their diplomas revalidated in accordance with current legislation;

III – those who, at the time this Law takes effect, can demonstrate that they have practiced the role of Systems Analyst for a minimum of five years

In other words, the interpretation leaves out self-taught individuals and students who chose not to get a formal degree for various reasons (see my article Should I Get a Degree?). The article excludes a good chunk of the most qualified professionals.

Even item III doesn’t spell out what “demonstrated five or more years of practice” means. Does an employment record count? Does an invoice for IT services billed to a client count? What are the criteria?

The analysis continues with the assertion:

Art. 4 of the bill, in establishing what the activities and attributions are, does not restrict the activities of other professionals. Nor is any exclusivity established or is it stated that any particular activity or attribution will be reserved for holders of degrees in the aforementioned professions.

Article 4 defines activities such as definition, management and coordination of software projects, explicitly including “coding.” That is, everything project managers, architects, programmers and the like do. And the same article gives us:

Sole paragraph. Technical responsibility for projects and systems for data processing, information technology and automation, as well as the issuance of technical opinions, reports or assessments, are exclusive to the Systems Analyst.

I may be misreading it, but that paragraph looks clearly exclusive to me and, once again, leaves out self-taught programmers. The analysis then falls back on some FUD:

One cannot imagine that the data processing center of a public body, financial system institutions, or even private companies could do without the technical accountability of a professional character, given the interface and synergy created with citizens, clients and consumers.

This is the wrong justification behind most arguments in favor of the law: that a formally trained professional is always far superior to a more experienced self-taught one. It’s the entire basis of my argument in my article from last year. I recommend reading it carefully.

To be fair to the analysis, it did at least suggest cutting the most serious parts:

• suppression of articles 7 through 33, which create the Federal Council and Regional Councils of Informatics;
• exclusion, in item III of art. 2, of the clause “… and who must register with the Regional Councils of Informatics”;
• exclusion, in item II of art. 3, of the clause “… and who must register with the Regional Councils of Informatics”;

Which brings us to the latest mess: the approval in the Committee on Constitution, Justice and Citizenship, published on 08/19/2009. The proposal passed with all the modifications suggested by the Committee on Science and Technology listed above.

Fortunately, the suppression of articles 7 through 33 was maintained:

… there is unconstitutionality of a formal nature in the provisions dealing with the supervision and exercise of the profession, as well as the registration of professionals and the payment of fees … These articles are therefore tainted by unconstitutionality, since parliamentary initiative to create public bodies and assign them functions is prohibited, by virtue of the aforementioned provision of the Constitution …

In plain terms, this removes the chapters that created the oversight bodies: the Federal Council of Informatics, the Regional Councils, professional registration and oversight, annual fees, emoluments and rates and, finally, infractions and penalties. Those would have been the most harmful parts if implemented. I really hope they stay out.

The Seventh Element

Since 08/20/2009 the substitute bill has been awaiting a rapporteur at the Committee on Social Affairs, where it can be approved or shelved. The way things are going, it looks like it’ll pass without much trouble, which is terrible!

My arguments in the article Let’s Stop the Regulation from last year still hold. Even after giving up the articles that created the whole bureaucratic machine and the penalties, it’s still a terrible law for the market. Worse: art. 7 of the current substitute bill makes me very uneasy:

Art. 7. The Executive Branch will be responsible for supervising and overseeing the practice of the Systems Analyst profession, and for the registration of IT professionals.

This single article replaces articles 7 through 33 without defining anything, leaving it open and arbitrary what the Executive will do about supervising and registering professionals. Deep down, everything that was removed is still implicitly valid.

This article didn’t exist in the 2008 version from the Committee on Science and Technology. It was the only thing added in the version approved by the CCJ on 08/19/2009 and is, in my opinion, what made the text regress the most. The report reads:

On the other hand, to give viability to the objective of this initiative, we also wish to add an article aimed at delegating to the Executive Branch the function of deliberating on the matters dealt with in the articles suppressed herein. Thus, we accept the Substitute offered by the Committee on Science and Technology, with the addition of a provision.

Conclusion

If the Committee on Social Affairs approves this law, it will be an enormous setback for the national IT market. It has the potential to be even more destructive than the market-reservation laws for IT from the 1980s, which left us almost a decade behind the First World in modernization.

As the SBC itself pointed out, this market should be free and self-regulated, which it already is in practice. There’s no need whatsoever for regulation of this kind.

I’ve said before that we can discuss a more realistic text. But this particular one is far too harmful to be considered. It would need to be rewritten from scratch by experienced professionals active in the field, together with the entire new generation of developers.

I know of no parallel to this law anywhere in the world (if anyone does, please comment here). It restricts the activity by starting from the wrong premise that formally trained professionals are always better than self-taught ones, which, from personal experience, is very false. Some of the best people I’ve worked with over these past 15 years had no degree.

Most people in favor fall into two groups: those who have read the bill and its proceedings, and those who haven’t. Those who haven’t simply don’t know what they’re talking about.

Those who have read it and still agree are exactly the bad professionals who can’t compete with self-taught people and want to lean only on the force of “credentials” as the criterion. This market self-regulates as bad professionals get naturally pushed into lower-value activities.

There’s also a confusion between the careers of “coder” and “developer.” The coder is a commodity, close to a typist, who just translates diagrams and requirements into code with no attention to quality. The developer is a born architect, with total control over their own creation. One is a commodity; the other is the “cream of the crop,” rising in the market through pure meritocracy and natural selection via networking. With some exceptions, I’d say it’s a reasonable implementation of laissez-faire.

Our field doesn’t even have a consolidated working methodology. We’re still moving from the Taylorist-Fordist Classical Software Engineering based on Waterfall to the post-Toyotist Agile movement of Lean, Scrum, XP and others. Our tools today and the ones from ten years ago are quite different, and the internet completely changed the course of the profession.

These changes are too sudden to try to regulate. In a scenario like this, the free market is the best way to deal with the problem.

For all of this, I remain vehemently opposed to this proposal and hope there are sensible people on the Committee on Social Affairs, with the good sense to ask society and us, the affected category, before shelving this text once and for all.

The first article is What makes a good programmer?

An Analytical Thinker

Programmers need to be problem solvers. The process of programming requires that we systematically break complicated problems down, plan and implement solutions and find / eliminate small inconsistencies in code (bugs).

Analytical thinking also manifests in the ability to follow complicated logic through disparate code segments and understand it. It allows us to grasp abstract concepts such as Object Oriented methodology and design patterns and implement it in practice.

Has Clear Priorities

If I would ask you to rate the following according to priority, how would you order them?

• Security
• Maintainability
• Usability
• Performance
• LOC (lines-of-code) count

Take a moment to think about that, and then consider:

1. If you picked LOC count first, you failed big time in my book. In fact, LOC optimization can often go directly against the other metrics (such as maintainability). A lower LOC count should never be a goal, only a result of careful application of well factored architecture.
2. If you picked performance first, you are probably the guy who keeps writing articles about how you should use a while loop instead of a for loop since it came out a few milliseconds faster in your benchmarks. You might be inflicted with a case of premature optimization.

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. – Donald Knuth

Performance should only be good enough to satisfy the requirements of the application. Aside from caveats to well-known pitfalls (such as executing queries in each iteration of a long loop), performance optimizations should be deferred to the very last and even then should be used appropriately (profile … profile … profile … optimize).

The only exception to this is if you are primarily developing performance dependent applications (such as low-level system drivers).

3. Security is on somewhat of a middle ground. Depending on the application and distribution model it can be completely useless or mission critical. It’s mostly somewhere in between, and thus can’t be ranked as number one.
4. Maintainability is definitely one of the most important attributes of a software application. High maintainability allows you to improve other attributes (such as performance), when it is needed.

Maintainability is the single most important factor for keeping productivity up and costs down. For a long time I strongly believed this to be the most important attribute of software design. However… 5. The most important attribute is usability. In the end, the worth of your application is only as much value as it delivers to the end-user.

We should always remember - software is not written to serve its developers or the systems they run on. They are written to solve problems. If those problems are not solved, then the project is a failure.

I wrote usability here as a more general term than just UI/UX effectiveness. Even a command line application or a background service has its usability factor in the sense of how well it answers a specific need.

Gets Things Done

In principle, it’s simple. You’re looking for people who are

1. Smart, and
2. Get things done.

Joel Spolsky

Quite possibly the single most important trait in a developer. You can excel at all the previous attributes and still be a mediocre programmer if you just can’t get things done. One average but productive developer could easily replace several highly talented but slowly moving developers, depending on his responsibilities.

At the end of the day you definitely want more highly-productive developers than those who are high on theory but not actual work.

Does More Than “Just Enough”

Getting things done is important. Getting things done “the right way” is even more important.

Constantly paying off your technical debt is crucial - if you keep accruing debt by “hacking” quick fixes that work now but are not maintainable, you only create the appearance of progress. In reality, the cost of getting rid of a large technical debt could become prohibitive before you know it.

Taking the time to constantly refactor code into a more maintainable state is the best way to prevent the spiral into project oblivion.

Accountable

A person could be a very capable programmer on technical ability alone, however if he does not own up to his mistakes and does not respect deadlines he could become a liability very quickly.

Responsibility also means to know where to let go of your ego for the good of the project. We developers often have large egos as we consider ourselves experts on many things. Putting the project first is a sign of a good developer.

Good Human Relations

Another all-around useful trait, this one applies to programmers as well. There is some stereotype that programmers are reclusive, unsociable creatures - programmers are still people.

In order to be a part of a team or handle clients, a programmer must have above basic social skills. Rudeness, arrogance, short-temper - do not have a place in a professional work environment. All it takes is one bad apple to ruin the mood for everybody.

That’s It

If you answer to all of the above, you are probably a pretty good programmer.

You might notice I didn’t mention passion or technological diversity as qualifying traits. Simply put, I don’t think they’re very relevant to the quality of a programmer.

Passion is nice to have, however I’ve known many very professional and high-quality developers who were just content to go about their work professionally from 9 to 5 and then go home and have a meaningful and fulfilling family life. A programmer can definitely be completely professional without being passionate about programming.

Technological diversity is another nice to have but not a prerequisite - as long as you are in command of the technologies you work with, a lack of diversity shouldn’t affect you too much. Decision makers need to be well aware of all the options before starting a project, however nowadays the choice of technology simply is not that important.

You can achieve good results regardless of the programming language and database engine among other consideration. The biggest consideration should be the type of skills available to your personnel.

[Translation] Why Good Programmers Are Lazy and Dumb

Source: blogoscoped

I realized that, paradoxically enough, good programmers need to be both lazy and dumb.

Lazy, because only lazy programmers will want to write the kind of tools that might replace them in the end. Lazy, because only a lazy programmer will avoid writing monotonous, repetitive code – thus avoiding redundancy, the enemy of software maintenance and flexible refactoring. Mostly, the tools and processes that come out of this endeavor fired by laziness will speed up the production.

Of course, this is only half the truth; for a lazy programmer to be a good programmer, he (or she) also must be incredibly unlazy when it comes to learning how to stay lazy – that is, which software tools make his work easier, which approaches avoid redundancy, and how he can make his work be maintained and refactored easily.

Second (and I will elaborate a bit more on this because I find the concept to be less known than the first) a good programmer must be dumb. Why? Because if he’s smart, and he knows he is smart, he will:

a) stop learning b) stop being critical towards his own work

Point a) will make it hard for him to try to find new techniques to allow him to work faster. Point b) will give him a hard time debugging his own work, and refactoring it. In the endless battle between a programmer and the compiler, it’s best for the programmer to give up early and admit that it’s always him and never the compiler who’s at fault (unless it’s about character encoding issues, which is the part even the compiler gets wrong).

But there’s a more crucial point why a good programmer must be dumb. That’s because for him to find the best solutions to problems, he must keep a fresh mindset and manage to think out of the box (or rather, know its actual shape). In a way, this leads to the mindset of a child; incredibly creative because he never heard “no” for an answer.

The direct opposite approach would not be very constructive; to be knowledgeable about the parameters at hand, and accept them. Because who knows how many limits you think are there for real? The less you know, the more radical will your approaches be; the better the tools you develop, and the better the product you develop with them.

I know from my work that a good programmer, when confronted with a problem from management, will adopt this mindset of being dumb; he will start asking the most simple, child-like questions. Because he doesn’t accept the parameters suggested to him that someone thinks make up the problem. Here’s a typical conversation from the lost land of web development:

• “Since yesterday, our client can’t see the logo on the web site.”
• “Did he restart his browser?”
• “Yes.”
• “Did he restart his computer?”
• “Yes.”
• “Did he empty his cache?”
• “Yes.”
• “Does he run Internet Explorer 6?”
• “Yes.”
• “Is he sure he can’t see it?”
• “Yes.”
• “Did he look at the web site on the screen?”
• “What?”
• “Well, he might have printed it out.”
• “No, he was looking on it on the screen.”
• “Did he also not see other images besides the logo?”
• “What? Well, I will ask him.”

For the sake of argument (and this was entirely hypothetical) let’s say the client indeed turned off images in his browser. Or his son did. Whatever the case, this answer could not have been found if you would work in “smart” mode¹. None of the questions asked by the programmer required any programming skills. No; simply because the problem is so stupid, only stupidity can tackle it.

¹ Some years ago, I had a long telephone discussion about the whole web site being messed up since my last update… it turned out the guy disabled stylesheets in his browser. Back then, I would have suspected everything but such a simple solution and was listening to half an hour of complaints about quality standards etc. In the end, the assumption that my update was at fault was just that… an assumption. You better listen to facts only if you start debugging, and never to what people think might be the reason.

In similar fashion, when one of my co-programmers asks me: “Why isn’t this working?” most of the time it’s because they’re working on the wrong file (e.g., they linked to library 1 but they’ve altered library 2, and their revision isn’t showing, or they simply didn’t link the library at all). When you ask a colleague for help, particularly in programming, you want him to know less about your project… so he will ask the stupid questions you sub-consciously avoided asking yourself because you thought you knew the answer, when in fact you didn’t.

There’s another side to it. The too-stupid person will just run off and, without a second thought, do something wrong. The too-smart person will sit down and plan something right, without taking any action. A pragmatic programmer is sort of in-between; he knows making the wrong decision 1 out of 10 times doesn’t hurt the goal as bad as making only right decisions 5 out of 10 times, and making no decision at all the other 5 times.

It’s like the story of the centipede. The centipede was very good at walking with its hundred legs. It never spent a thought on just how it could walk. Until one day, when a big black bug asked the centipede “How can you manage to walk with all those feet? Don’t you find it hard to coordinate their rhythm?” The black bug already left, when the centipede was still sitting down, pondering how it could walk, wondering, and (for the first time in his life) even worrying a little bit. From that day on, the centipede couldn’t walk anymore.

So you better not think too much if you want to achieve something. And of course this is only half the truth, too…

The short answer? When in doubt, go. Okay, let’s get to the longer answer.

Today’s Colleges

Like Paulino, most people have the sense that college “doesn’t prepare students for the job market.” Others say exactly the opposite: that the problem is colleges focusing only on the job market and neglecting the academic side.

For me there are two types of college. The first are the traditional, serious ones, like the federal universities and a few state ones: USP, Unicamp, UFRJ, ITA. These are seen as the ones that “don’t prepare students for the real job market.”

The second type are the commercial ones, with their fast-food two-year degrees or less, instant diplomas, do-two-courses-in-one deals. I won’t name names because they’re obvious. These are seen as the ones that “focus, barely, on the job market.”

A college’s goal should be much bigger than preparing someone for “the job market.” It’s the final stage of the formal educational process that starts in grade school and prepares a person “for life.” Preparing them to grow on their own, to value self-knowledge, respect for others, civic duty. Building a taste for discovery, for rational and independent thought, for systematic trial and error in the name of continuous improvement. Over more than ten formal years, the system should teach students to think and act on their own, aware of their own actions, with the scientific method above all.

Instead, students leave the educational system with a different proposition: I’ll do whatever I’m told to do, everything I’m told is true and needs no verification, and everything I’ve learned so far is enough to consider myself a good professional. In short, the student leaves college with their values completely corrupted. Half the blame goes to the system, the other half I place on the student, because I went through the same system myself.

The colleges considered top-tier, like USP, still have a more academic scope, and therefore a more experimental, more challenging, and more interesting one. If the student is willing, that can genuinely open doors. Students at these schools have more time, usually more purchasing power, and, with the right mindset, access to professors and material with far more depth. I’m generalizing: not all professors are good, not all students are engaged. But that’s not the norm there.

Commercial colleges have a single objective: being diploma factories. They present, in an absolutely superficial and disposable way, all the technical terms and basic procedures that entry-level jobs tend to ask for. They’re pieces of a cruel puzzle whose only goal is to trivialize education and the craft. Again, I’m generalizing: good professors and well-meaning people exist. They’re just not the norm.

The traditional educational system as a whole is built on dogmatization far more than on actual learning. Through the end of high school, every student is a memorization machine. Commercial colleges keep the same rhythm: memorize, take the tests, get a diploma. Simple, easy, no effort (I repeat: no effort).

My Experience

I’ve told this story before. About six years ago I decided to try a certain renowned commercial college, just for kicks. I scheduled the entrance exam for a Saturday, spent the previous Friday night hopping through three or four clubs with no sleep at all, and took the test literally still in post-club mode. I finished in half an hour, because it was absolutely trivial, and obviously passed. Let’s just say this college’s name is recognized by every company in the market.

It was so frustrating that I decided I wasn’t going to waste my time somewhere that easy to get into. I didn’t even bother to enroll.

Fifteen years ago I took the entrance exams for Fuvest, Unicamp, and Fatec, only those three, and passed all three. It was much harder: a full year at the same frantic pace of study, at least ten hours every day, weekends and holidays included. Thousands of exercises and practice tests, and even then I didn’t reach the top of the list.

Spending some time at USP was a great experience, even though I dropped out three years in. My reasons are personal and apply only to me, which is why I say I don’t recommend anyone copy me. I left because I was certain I could learn the rest of the curriculum on my own, and faster. But don’t get me wrong: I never thought what I was learning was unimportant. I had already been a programmer for at least five years. The first years at USP massively accelerated what I already knew and helped me take much bigger steps.

Even though I was at IME (Institute of Mathematics and Statistics), my best friends back then were electrical engineering students at Politécnica. That’s the crowd that taught me Unix: guys who played with assembler over lunch, did computer graphics in their spare time, and still had time to design microprocessors before dinner. I watched Java, Delphi, HTML, and JavaScript being born alongside those people. And I had broadband internet access fifteen years ago, thanks to the university.

That crowd left a strong impression on me: students only a year or two older than me who seemed to have ten more years of experience.

Talent and Effort

For me, college was extremely valuable and a hugely important step toward who I am today. I didn’t finish by choice. Now comes the hard part: software development is not a repeatable manual craft. Like advertising, music, literature, medicine, architecture, and every great profession, it demands innate talent. Nobody learns to be a great musician: you’re born with the talent and learn to refine it. You don’t learn to be Da Vinci, or Mozart, or Niemeyer, or Villa Lobos. Either you’re born Da Vinci or you aren’t. Sure, you can always learn the techniques, but you won’t get very far.

College won’t make you a talented person; at best it helps shape your talent. Many people discover in college that they’re on the wrong path, and many only find out much later. Unfortunately that’s common. Some people are aware they still don’t know what they want. Worse: many don’t even know that they don’t know yet.

Something else that matters: a talented person is never satisfied with what the system hands them, with what college or some course teaches. They always want more, much more. People like a Linus Torvalds, who creates a kernel from scratch. Like a Miguel de Icaza, who creates platforms from scratch. Like a Joe Armstrong, who challenges the status quo and creates a language like Erlang; like a Damien Katz, who creates different ways of handling old problems like databases, creating CouchDBs. People like Don Chamberlin and Raymond Boyce, who created the original SQL. People like Alonzo Church, who went deeper into mathematical disciplines like lambda calculus and opened up new forms of programming. People like John von Neumann, who literally laid the first brick in the foundation of computing.

Education is much more than learning a micro-trade, a series of mechanized tasks that can be repeated. There’s a place for that kind of work, sure. But if you’re reading this article, we’re definitely not talking about painting walls or stacking bricks.

Many of the best programmers were already programmers before college. It’s not a requirement, but it’s common, especially nowadays, for the urge to program to show up well before entrance exams. That makes things easier, because there are fewer doubts. In that case, invest as much as you can in the talent you believe you have and get into a college capable of shaping what you know.

The biggest mistake I see is great potential entering bad colleges just to grab a diploma. They believe they’re already good (they aren’t yet, they only have potential) and that therefore they don’t need college. That’s two mistakes. The first: a bad college makes you waste time chasing a diploma with no value at all. I personally don’t hire anyone based on a diploma, and neither does anyone truly serious who values knowledge.

The second mistake is reducing software development (including web development) to a mere set of specific pieces of knowledge. Thinking that knowing JavaScript, HTML, Linux, Apache adds up to a sufficient collection. Think about the painter again: a great painter either knows how to paint the whole work or doesn’t know how to paint at all. A good chef either knows how to make every dish or none. A musician either knows how to compose a complete piece or nothing. There’s no knowing the pieces, however well, and thinking you know enough.

The Worker and the Artist

That mistake is fatal, because the individual will readily believe they know enough and give little or no attention to everything else. Software development is an art like any other. You’ll never be perfect in all of its aspects, and the peculiarity of all these creative fields is precisely that they prize the “pursuit of perfection.” What counts is the rung above the one you’ll be on tomorrow, and the wisdom that this ladder has no end. What matters is the journey, and the journey in pursuit of perfection is the engine of continuous improvement.

As they said of Socrates: “the more I learn, the less I know.” Stop for a moment and think about that again: most of us forget this principle. Diplomas and certificates do harm precisely because they discourage the long-term journey in exchange for false short-term trophies.

You think you really don’t need college? Do you know probability and statistics? Because without them you can’t build the most advanced anti-spam and anti-virus mechanisms. Think you understand linear algebra and calculus? Without them you’ll never create anything in computer graphics. Do you really think you understand algebra? Without it you’ll never grasp how cryptography mechanisms work. Did you actually learn boolean logic? Without it you don’t understand the foundation of modern computing. Think quantum physics is irrelevant? Without it you can’t even begin to imagine the possibilities of future quantum computing. Before the cynics take this too literally: I’m not asking for expertise in any of these areas, and I don’t have it myself. But I know where to look to solve each problem involving each of them.

Plenty of people find all of this very irrelevant. After all, why would a programmer need to know all this nonsense to be a mere “form coder”? The thing is, in the end, the bulk of “the job market” is building forms: forms in Visual Basic, forms in HTML, it’s all forms. For that I don’t need Da Vinci; a house painter will do.

If your purpose as a “programmer” stops there, this article ends here and I’m wasting my time. I build forms too, but I’m not content with that and I keep inventing different ways to build them. A Da Vinci doesn’t choose or plan when or how his Mona Lisa will come out. It’s the result of a long, laborious, difficult journey. The Mona Lisa began to be painted in 1503, he put the final touches on it until shortly before his death, around 1519, and that journey took him from Italy to France in 1516. It only started becoming truly famous in the mid-19th century. He made hundreds of other paintings along the way, some better known, some ignored.

On top of that, knowing every aspect of the profession makes even the task of “coding forms” more interesting. A mediocre coder will code forms the same way for the rest of his life. A good programmer always looks for different approaches, experiments with new techniques, refines the ones he already knows, exactly as they did in the Renaissance. That’s where the whole school of software architecture came from, the best practices, the best architectures, the entire process and discipline later taught as rote memorization to the mediocre.

Data structures, basic algorithms, relational databases, compilers, assemblers, operating systems, protocols: these are all disciplines that should be considered trivial. The challenge lies elsewhere. For an artist it’s the same as knowing how to hold a brush or handle a piano’s keys: what makes the difference is how you use them. That takes talent, that takes experience. Even the most talented person will need years of practical experimentation, thousands of hours of practice, trial and error, refinement, before reaching expert status. A good programmer should aspire to become a polymath.

By polymath I mean knowing programming, some administration, some marketing, general culture, communication, and various other areas that add to your main craft. The current “social networks” craze makes much more sense once you become familiar with the work of scholars like Albert-László Barabási on scale-free networks, a discipline that didn’t originate in computing but precisely explains the evolution of this kind of natural formation. For those leaning toward a management career, understanding Frederick Taylor gives you another perspective. More “modern” topics like agility or lean make much more sense after you’ve seen the work of others like W. Edwards Deming or Taiichi Ohno.

My point: you won’t pull anything useful out of your own head alone. Forget that idea. You only sharpen what you know, at genuinely high speed, by standing on the shoulders of giants. In my case, I think I just absorbed that insight and consciously changed my attitude by going through college, in an environment that let me experience my own smallness before decades of cultural and academic evolution. You need to feel like a dwarf in order to pursue surpassing giants.

Today’s traditional and commercial environments of teaching and work are unfortunately terrible places for that, I’d say the worst in the world. In them you live the illusion of achieving more without pushing for more, in a predatory environment that rewards the fast and the superficial. Fast-food culture is completely hostile to the concept of continuous improvement, which by definition depends on time and disciplined effort. Today everyone wants a short college that’s easy to get into, easy to pass, preferably cheap and low-effort. Courses and certificates follow the same path: in no time you get to call yourself a “sage” in some field. Instead of a meritocratic environment that values learning and wisdom, we have an opportunistic one that values smallness, minimal effort, and low culture.

A Recipe?

With all of that:

• If you’re still of school age, in high school, do everything you can to figure out what you think you like. You’ll rarely be certain, but you need to try.

• If you’re past school age and still don’t know what you want to do, I’m sorry: few people leave that condition for a position of distinction. Rare isn’t impossible, but in that case understand that you’ll need to work much harder than average, much harder than most naturally talented people. It will literally cut to the bone, it will hurt, and there’s no guarantee of any return.

• If you know what you want, go for it. But really go. Understand that the journey is long and has no end, that you’ll never reach the top, and that there will always be many people above you, with the aggravating detail that they keep climbing fast. The reward: if you engage with the journey, you’ll never have to separate work from fun. Let others decide whether what you’re doing is work.

Now the most complicated part of the equation: few people have the conditions for any of this. Most aren’t just opportunists; they’re in a situation of real financial distress, sometimes with even graver family problems. It’s that terrible situation of having to choose between what you want and what others want, where either choice will be a bad one.

I have no magic solution for that, nor do I have that life experience. But I know up close, in detail, cases of people who managed to escape the negative cycle and became far more successful than me. There’s a price: it will hurt. No great reward comes for free. No great value comes in the short term.

What I see most are people wasting a lot of time feeling sorry for themselves. I hate that type, acting like the victim of everything: the system is to blame, the company, the parents, everybody but themselves. There are always people in much worse situations than yours. Never assume you’ve hit rock bottom, because you have no idea how deep that pit goes. And if you’re here reading this blog, I can assure you that you’re very far from that bottom, so you have no excuse.

The old saying still holds: “no pain, no gain.” The important thing is not to be a conformist. Most people who criticize me when I say these things start from the wrong premise: they separate what is work from what isn’t. That person already is a conformist: they’ve already accepted that their job is something they don’t want to take home. And I’m not talking about taking paperwork home to do at midnight. I mean the journey, the mindset, the thinking, the reflection. What’s the right balance? Each person knows their own.

Outliers

As Malcolm Gladwell tells it in his recent Outliers, the Beatles went to Hamburg five times between 1960 and 1962. They played eight hours a night, seven days a week, trying to win over an audience that didn’t speak their language and was more interested in the strippers. That was 270 nights in Hamburg. When “I Want to Hold Your Hand” finally broke in America in January 1964, the Beatles had already performed some 1,200 times. That’s far more experience than most new artists accumulate in a lifetime.

You don’t need to become the Beatles; that’s nearly impossible. Nor a Bill Gates, a Steve Jobs, a Ray Kroc, a Henry Ford. It makes no sense to try to imitate them, follow their footsteps, take the same courses, do the same things, wear the same clothes. It’s futile and it gets you nowhere: a biography comes nowhere near being a recipe for success. You need to absorb what drove them to the journey, not what they did during it.

What they all have in common is talent, a lot of hard work, and a lot of experience. Mozart started composing at six, but it was only after his twenties that he finally composed a work of art: more than ten thousand hours of practice later.

So I return to the question: “Is college worth it?” Certainly, if it’s a good college, with the intent of sharpening what you know and learning more. Very much worth it, as long as you understand that college is only a fraction of your journey of at least ten years of learning before you can finally say you know something.

My journey in computing began timidly in 1986 and picked up steam from 1989. My “formal” résumé starts around 1997. I’m still very much a novice in many areas I’d like to know more about. My journey has barely begun. Don’t think yours is already over.

Do You Need a College?

After all of that, you don’t expect an easy answer, do you? :-)

To be mediocre, by definition doing what everyone else does, yes: you’ll definitely need a college, any college, grab your diploma, and be just another one in a crowd of millions. Good luck, you’ll need it.

To be above average, the only path worth taking, it depends. If you think you can learn everything on your own, that works too. I know several cases like that, of extraordinary people who never went to college (or went to a bad one, just for appearances, without letting it influence them) and who know every aspect of the field. Understand: knowledge is not a secret. There’s nothing you’ll only see after opening some secret door inside a college. All the information is out there. It’s up to you to decide whether you’ll go after all of it on your own. If you don’t think you will, go to college, but a decent one, not one of these disposable commercial operations on every corner. I think it’s worth it.

But if the question you really wanted to ask was “Is college decisive for a successful career?”, then the answer is no. Success depends solely and exclusively on the individual. If you succeed, the credit is all yours; if you fail, the blame belongs to no one else either. And once more, for the cynics (whom for some reason I suspect are intelligent and love pulling things out of context): no, nothing I said here is new. I’m just repeating what should already be common sense.

The executive summary, in Schulmeyer’s own words, is this:

“Taking a poor performer off the team can often be more productive than adding a good one.”

Found out you have a bad programmer? Fire him, as fast as possible. There’s no other solution. Many managers assume that bad or mediocre programmers are, at worst, just slower than the good ones. That assumption is absurdly wrong: a single bad programmer causes irreparable damage to a project and literally puts the team in reverse.

The damage isn’t always obvious. Most of them are accumulators of Technical Debt (note 2012: this post talks more about technical software problems, but generalize to problems in general, like low team morale, dissatisfied clients, etc). Maintainability and extensibility end up deeply compromised.

One thing is certain: spotting a bad programmer is very hard, especially if you, the manager, aren’t a programmer yourself. Worse: you need to be a good programmer to recognize the bad one. In a reasonably balanced team, with programmers at least slightly above average and only one or two bad elements, the team itself separates the wheat from the chaff and expels the rotten apple from its midst (if they’re smart).

That’s a double-edged sword. If you, as a programmer, think your colleague is the bad one, who guarantees the others don’t think the bad one is you? If you’re a programmer, make sure your work speaks for itself.

I tend to separate “coders” from “developers.” Both are programmers, but the first group clocks in at the door, does only what they’re told, goes home at the same time every day, and worries about nothing else. The second group is made of true artists, people who understand that software is art and, as such, demands dedication and constant study, with no regard for business hours. As I like to put it: it’s the difference between a house painter and Da Vinci.

A manager needs to be very conscious of this: every software development team needs Senior Technical Leaders. Tip: look in Open Source communities, your odds of finding the best programmers are better there. Don’t look in educational institutions and, above all, be suspicious of any programmer who leads with the certifications they have.

I liked what Kris Kemper wrote on his blog about how ThoughtWorks hires: the candidate goes through a battery of tests. One or two interviews won’t cut it: they need to get past several senior engineers and show code that other seniors will review. They have to truly earn the seat. They need to demonstrate experience (following Malcolm Gladwell in Outliers, I’d say you should only hire programmers approaching their 10,000 hours of experience, at least for roles with less important tasks), they need to show resourcefulness and excellent communication skills, they need to show code, and good code, code that wouldn’t embarrass them in front of Martin Fowler. (note 2012: that model isn’t bad, but today I think there’s a better way, which is a topic for another post.)

Now, I’ve seen very bad situations where an entire team is made of NNPPs. In those cases there’s nothing to do: dissolve the entire team. Be very careful not to fall for the Sunk Cost fallacy. Many think like this: “but I’ve already invested so much time and resources in this team, it would be a waste to throw all that away.” No. What’s wasteful is keeping them around while they create more and more technical debt that you’ll be the one paying for. It’s cheaper to dissolve the team, form a new and better one, and restart the project from scratch if necessary. You’ll stop for 6 months, but at least you won’t go bankrupt in 2 years.

Another thing every manager always gets wrong: immediate results versus long-term results. This is a constant in every company I’ve been through: the manager loves the cowboy programmer, the guy who solves every problem thrown at him. All cowboys are devotees of what we call POG in Brazil, “Workaround-Oriented Programming” (in Portuguese). It would be funny if it weren’t tragic: it exists, and it’s practically the norm in most software teams. I’d risk saying that at least 4 out of every 5 programmers do POG daily.

So if you’re a manager, be suspicious of magical results, unexpected software behavior, constant bugs fixed instantly. You know the pattern? A problem blows up today, you send an email to the team, they reply an hour later saying “everything’s fine now.” And this repeats every single day. That’s a very strong POG signal. Cowboy programmers are “coders” who think they’re “developers”: an insane house painter who thinks he’s Van Gogh. It’s the most dangerous type, because the house painter knows his limitations and would never claim to paint portraits, but the cowboy genuinely believes he’s Van Gogh. And the worst part, paradoxically, is that managers love them because they solve all the problems.

Now for the shocking part: managers love cowboys because they solve all the problems they created themselves. The penny hasn’t dropped yet: all the merit credited to the cowboy is generated by the problems he created. If you’re this type of manager and it just clicked that you have cowboys, fire them too. There’s even the classic dilemma: “but I can’t let him go, he’s the only one who knows how the system works!” Exactly. That’s an even stronger reason to let him go: he is, literally, a massive Single Point of Failure (SPOF). Real developers don’t hide things, don’t mask results, don’t stall the process. Want a symptom? Is there any software whose source code lives only on your programmer’s machine? Watch out: you just found a cowboy.

One more motivator: when you swap a bad programmer for a truly good one, the effective gain is 1 for 10, as the good old Frederick Brooks put it in The Mythical Man Month. For 30 years we’ve known that a good programmer can be 10 times better. On top of being faster, he writes quality code, which makes maintenance, extension, and knowledge transfer to other programmers easy.

And these days there are several symptoms that expose cowboys who should be fired. Does your programmer wrinkle his nose when Pair Programming comes up? Does he scoff at Collective Code Ownership and prefer to keep some code hidden? Does he think testing is optional, something to do later? Worse, does he defend the use of practices or technologies without being able to explain, technically, why he’s using them? All of those are symptoms. Even one of them is reason enough to have the dismissal paperwork ready and start interviewing new candidates.

By the way, I might sound like I’m joking when I say “fire them,” but I’m dead serious. Another thing that’s very important for a company is staff turnover. When the same people stay together for years, they get too comfortable with each other and start turning a blind eye more often, drastically dropping service quality. One goal worth adopting: renew 10% to 20% of the staff every year. Keep the true developers and fire the NNPPs, unless, of course, you have money to burn.

Update 03/30: I forgot to mention a few more things, responding to some of the comments as well. As I already said in my Killing the Average talk, the market as a whole benchmarks everyone from the bottom. So a good programmer, even being up to 10 times better than a bad one, never earns 10 times more. Sometimes the difference barely reaches 10%, which is truly sad. Of course when I say “fire them,” I mean it, but it’s also a provocation. Given Brazilian laws that protect the underperforming professional, in practice it gets difficult. So the pragmatic approach is: fire whenever you can and, more importantly, hire with great care. It’s always better to take longer and hire someone truly good than to assume someone might have “potential” based on credentials alone.

One important thing: don’t read this as an attack on newcomers, juniors, and recent graduates. There are many young folks with lots of potential, especially those who know they’re early in their career and want to learn, make an effort to learn, change course when they receive feedback, and know at least how to start arguing their positions. A cowboy can be a recent graduate or someone with 20 years of career, it doesn’t matter. Good juniors should be well taken care of and given adequate coaching so they don’t go down the cowboy path.

One more thing: “I want to be a good programmer, but my boss pressures me to deliver everything early, he even encourages POG.” Alright, here we go. In aviation there’s the so-called co-pilot’s Catch-22. A few decades ago many planes crashed because the captain made wrong decisions and the co-pilot, even knowing this, stayed silent because of hierarchy: someone of lower rank must not contradict someone of higher rank. The aviation world evolved and now there’s a procedure called PACE (Probing, Alerting, Challenging, and Emergency Warning). If the co-pilot knows the captain is wrong, there’s a procedure for him to assess the situation, alert the captain, challenge him if he doesn’t understand and, if the error persists, the co-pilot must notify the control tower and take control of the aircraft. That culture shift in the cockpit helped bring aviation accidents down drastically.

A good programmer must say no to a boss who is pushing the team off a cliff. If the company punishes that kind of initiative, that company isn’t good for you. Skip the childish move of going around your boss to gossip with his boss: face the man and discuss the problem like an adult. Here’s a passage from the PACE paper:

For the actual announcement of change of command on the flight deck, the Co-pilot could use a phrase such as “Captain (Jones), I must take over control of the airplane. (Jerry), take your hands off the controls. NOW!” This use of a personal first name or a nickname can very effective to break the perceptual narrowing of the Captain. A third crew member, if present, can use terminology such as, “Captain (Jones), you must give control of the airplane to (Barry) immediately.”

Update: 03/31 I think it’s worth digging a bit more into the “Cowboy” concept, since it can be misread. Again: the newcomer gaining experience and the senior learning new things are not cowboys. Those are the ones worth investing in. The problem is the Lemmings, the suicidal ones: the guy is bad, everyone knows he’s bad, everyone warns him he’s heading toward a cliff, but the damn fool has it in his head that he can’t change, won’t change, or doesn’t know how to change, and therefore he won’t. That’s the guy who keeps going off the cliff and drags everyone around him along. That’s exactly the NNPP: negative productivity, guaranteed damage. After being warned once, twice, there’s no point anymore: he has to go, because at that point it’s him or you.

In recent posts I explained why “mediocre” thinking is a problem and why there is no such thing as “average” in the real world.

Some readers already asked me for book recommendations, and I dropped a few important ones in recent posts. The Black Swan is at the top of the list. It explains how we ignore “black swans” and why trying to predict the long-term future from past events is an exercise in futility. The core point: we instinctively “reduce” and “simplify” everything to make it digestible, and that is a problem.

Now I want to explain how the modern hero has trivialized the great myths.

Modern Heroes

Another book I recommend, not directly related to the subject, is The Power of Myth by the great Joseph Campbell. It’s a fantastic book and it describes, among other things, the Hero’s Journey. Every civilization had its myths, populated with heroic figures.

The short version: the Hero’s Journey starts with someone just like most of us, at the “average” or below it. The road is packed with danger, temptation, and trials. In the end the hero completes the journey and returns to preach what he learned. It’s one reason myths like Buddha’s or Jesus’ are still told today: they are heroic allegories baked into every culture.

Every Star Wars fan knows George Lucas is a Campbell disciple. Luke Skywalker’s story is the hero’s tale beat for beat: a poor kid from the backwaters of Tatooine faces trials and the temptations of the Dark Side of the Force until he transcends himself and returns to his people as a hero. It’s one reason Star Wars is a classic to this day.

The modern world still has its heroic stories. These days some of the heroes are successful businessmen: Steve Jobs, Jack Welch, Henry Ford, and many others.

We all like having these “heroes”. Their stories inspire us and, as a side effect, sell mountains of books and merchandise, like courses and certifications.

Today’s self-help is a poor man’s version of ancient mythology. And in this market bent on manufacturing the next heroes, pitiful copies fight over the spot of the next Perseus.

Charlatans

All this hero talk was the setup for the point that matters: how easily charlatans fool us, and how to break the cycle.

Ask Campbell, but the need for heroes to model ourselves on is probably in our nature. Nothing wrong with that: the names I mentioned above are reasonably worthy of the “modern hero” title.

The problem is the charlatans selling themselves as heroes, and plenty of them pull it off. Today’s “Leader” is yesterday’s “Hero”. I searched for “leader” on Submarino’s site and the results alone show the size of the gold rush: a flood of books on the same theme, “How to become a leader”. Probably the best-selling category in corporate self-help.

First things first: self-help is a giant exercise in futility. If you can avoid it, avoid it, because almost all of it is a waste of time. Publishers were never good filters, so there will always be a mountain of worthless books. The job is separating the wheat from the chaff.

Plenty of people say you should read a lot of books, and they’re right. They just forget to add that not every book counts. Reading bad books makes you dumber; if those were the only books around, I’d tell you to stop reading. Remember Pareto: maybe 20% of all books are worth anything.

A book titled “How to Be…”? Skip it, waste of time. To see why, ask the most obvious question: did any of history’s great leaders need a self-help book, course, or lecture to become memorable? Can you picture John Kennedy, Martin Luther King, or Abraham Lincoln reading “How to Become a Leader” backstage? Hardly.

Now the second question: how many people around you actually became good leaders because of that material? I’ll go further: there are dozens of project management “methodologies” promising miracles, and everyone buys in.

The Great Fallacy

The logic goes like this: you apply the technique or methodology and, if the project succeeds, the method gets all the credit. “Of course it worked, thanks to the revolutionary methodology.”

If the project fails, it’s your fault, because you obviously didn’t follow the methodology properly. Had you followed it, everything would have worked!

See the absurdity? All those management, leadership, and results books and courses hide this exact trick: they list dozens of people and companies that benefited from their “techniques”. I’d bet those projects succeeded because of the quality of the teams, the people who executed them. The methodology only showed up afterwards to take the credit.

These were teams full of people able to route around every obstacle, who subverted the “methodology” until they hit the goal. They would have gotten there with or without the recipe, and probably sooner without the magic-formula baggage.

I personally like the Agile philosophy. Many people prefer to say Agile “methodologies”, but I prefer “philosophy”. Methodology implies a systematic recipe you can repeat in any scenario, which isn’t true. If the team lacks awareness and discipline in the philosophy, you can implement the techniques all you want and the project will never be truly Agile. Writing on sticky notes, slapping them on the wall, and timing 15-minute meetings doesn’t make any company agile.

In the modern age we think we’re smarter, sharper. Are we? We chase the heroes who beat the odds and, as Nassim Taleb would say, we want to take their experience and their recipes and apply them to our own projects. In other words, we plan our future based on the past success of the people we call heroes.

Worse, we still “adapt” those recipes, convinced we know better. Take the reputation of the so-called “Waterfall process”, the staircase process, considered one of the worst ever created for software development.

Waterfall was described in the paper Managing the Development of Large Software Systems, from 1970, by Winston Royce. That’s the paper with the famous staircase diagram. What few people know is that Royce himself wrote in it: "…the implementation described above is risky and invites failure." He already proposed running the process at least twice, which means he knew it would evolve into something iterative.

We love leaning on past successful projects, on masters and scholars with magic solutions. The vast majority simply doesn’t do the homework and falls for the fairy tale like naive kids.

Here’s another thing almost nobody questions: has anyone empirically checked how many of these training-formed managers go on to have consistently successful careers? I never met one. I also never saw a single credible number on it, from a credible institution, in any relevant independent study.

Manufacturing Managers

I’ve sat through every kind of lecture and course on managing projects, dealing with people, being a leader. In a Gaussian world, where the whole educational system incentivizes the average, students hit the job market and suddenly there’s a shortage of people above average.

Of course there is. We raise people in a paternalistic, protectionist way, the worst way to raise anyone. In school we only study what we’re handed, only do the homework we’re assigned, only study to scrape a passing grade. We’re so used to taking orders that the outcome is plain for everyone to see: excellent factory workers, few thinking professionals, and very few great leaders.

I like to say that “leaders aren’t formed, leaders form themselves.” The way to encourage future leaders, starting in childhood, is to rip out the average mindset and raise them in a meritocratic environment: one where merit gets rewarded far more than mediocrity. And when I say “far more”, I mean absolutely unequal.

A democratic, evolving civilization was never about forcing equality, artificially lifting the weak and dragging down the strong until everyone lands on the average. “Equality” simply means nobody will stop you from rising above the average. Most people confuse that with making everyone the same.

The correct solution is the opposite: keep a high level of inequality based on merit. That’s how the real world works: the successful are orders of magnitude wealthier than those who barely try. Wealth in capital, but also in recognition and influence.

Companies keep doing the opposite: they rerun the grade-school playbook, stick employees in a classroom, and expect great leaders to walk out.

I know how this works: I’m a PMP-certified Project Manager, certified by the PMI, the “renowned” Project Management Institute. And I’ll say it out loud: it’s one more of the great corporate lies so common these days.

It works like this: you’re required to sit through 2 or 3 months of classes to learn the “trade” of being a manager. You learn to break a project into a WBS, build a Gantt chart, calculate slacks, draw a project chart, analyze risks (in Gaussian fashion!), and so on.

You get a workbook, you do homework every week, just like grade school. At the end comes the “entrance exam”: the certification test, 200 questions. Beat the cut score, barely more than half, and you get a handsome PMP diploma, a lapel pin, a signature template for your business card, and the right to sign your emails “Fabio Akita, PMP”.

Does any of that make you a better manager? If you were truly awful, at least you climb out of absolute awfulness and land near the average. Don’t be too proud of that.

But does it create good managers? Absolutely not. At best it proves you can read well enough to get slightly more than half the questions right in 4 hours, which proves exactly nothing. After the brainwashing and the rote memorization, anyone gets good at passing tests. Anyone who survived a cram school knows: a management course is the same deal.

I’ve met many project managers, more than I’d like, who are notoriously terrible. And they passed the PMP exam! When you get certified you’re happy, of course, I was. But if you’re smart, you start feeling embarrassed about the title once you see the other bad PMPs out there. That’s when I stopped using mine, even after a process that cost me around R$ 5,000 (a piece of paper doesn’t come cheap), plus dozens of hours of mock exams.

Oh, and we become Leaders with an expiration date. Mine expires in 2009…

Manufacturing Leaders

Anyway, if your resume is weak and you know you can’t deliver, go ahead and get certified in as many things as possible. The certification market exists because people never learned in school how to actually learn.

Everyone only learned to study what they’re handed and to pass the test, at the average. I’ve met few truly self-taught people with real street smarts. Those are exactly the ones who couldn’t care less about certifications. A very smart acquaintance of mine, one I unfortunately had little contact with, put it to me straight: “good people don’t get manufactured.” Indeed.

And by the way, acing a test and being intelligent are two very different things. You can get perfect scores across the board and still be far from smart. I’ve known plenty of straight-A nerds who turned into slightly-better-than-average factory workers.

Our concept of the hero has changed a lot. For me, the Hero figure was always a strong influence on how I act: outliers who single-handedly went from zero to empire. I always admired the great Renaissance artists, like Leonardo da Vinci, who broke barriers as a painter, sculptor, inventor, philosopher, anatomist, physicist, and mathematician. And other giants like Thomas Edison, Benjamin Franklin, Carl Sagan, Stephen Hawking, and Charles Babbage, all of whom I met reading encyclopedias in junior high. Yes, encyclopedias were not made to be decoration.

Luckily, my upbringing always pushed me past the average. If I came home with a 9, my mother would say: “the test goes up to 10; if you’re missing 1 point, you didn’t try hard enough.” If I got a 5, the average, I was grounded. My father, for his part, always prized self-knowledge: he bought books and science magazines, and once gave me a world globe for my birthday.

You’re a company and you want to grow great leaders? Put big challenges in their hands, push them to the limit, squeeze out everything they have. Be a tyrant without being a dictator. Demand perfection, and know how far each person can go. Only those who overcome extraordinary obstacles are extraordinary people. Leaders are Heroes, by definition!

Now, you don’t earn “leader” from a job title. Subordinates’ respect through sheer hierarchy is worth nothing, zip, zero. A structure where the only form of command is the old “chain of command”, where the subordinate obeys because his job depends on it, is a company extracting a tiny fraction of what it could. That’s why I’m against hierarchical organizations. As I mentioned in the other post, hierarchies are one more Gaussian form of control through the average, and it doesn’t work. Insisting on the mistake only makes everything more wrong.

The Death of Heroes

Here is the problem with Gaussian thinking: in a world that incentivizes the average, there’s little room left for Heroes. By that logic, the heroes who do exist are “accidents”: Gaussian probability says the odds of a hero appearing are so small they’re nearly zero, something no “normal” person could ever reach. Not even worth considering. The “safe” move is staying at the average.

Except heroes exist, and new ones show up every day. Open Forbes and look at the list of the world’s richest people. Take the top 500: the last name on that list is already infinitely richer than any of us. Stretch it to the 10,000 richest and the last one is still far richer than anyone you’ve ever met. Keep going down and you realize there are thousands of small heroes: people who left the “normal” path and won. And not only in money.

There’s another problem in the world of the average: plenty of people know the “trick”. People would even like to be heroes, but it’s work. Everyone knows the hero’s path takes a monumental, highly risky effort: the middle of the Journey is packed with trials, dangers, and the devil’s temptations. Nobody likes suffering for an uncertain future. People are naturally short-term thinkers; they love to “say” they plan for the future, but that’s just rhetoric.

And the people who know this trick best are precisely the ones who invent the magic recipes, the methodologies, the step-by-step procedures for becoming a hero in 24 hours, no sweat, no effort, no risk. For a small fee and a few hours of your day, anyone becomes a hero, certificate included! Companies hire these fast-food heroes, hand them command positions, and subordinates obey through the sheer force of the title. Could it get any easier?

As I said, there’s no empirical data proving these methods work. Companies simply “believe” they do. The trainers’ pedigree looks good, other companies swear by it, the references are great. Why doubt it?


Everyone falls for the fallacy of showcasing only the projects that succeeded, where the people did the heavy lifting, and “forgetting” to list the ones that applied the methodology and sank.

It sounds so smart when the trainer says: “as a Leader, you need to motivate your team.” He just forgets to explain, step by step, how you actually “motivate” someone. Of course nobody explains it. Worse: as Taleb describes, people get reduced to stereotypes and roles, inanimate puppets that, according to the magic recipe, are predictable and easy to control. Just “motivate”, just “incentivize”, just “be communicative”. Building attractive, empty rhetoric is easy. Actually leading a project to success is hard.

An acquaintance of mine used to say: “He who can, does. He who cannot, teaches.”

And according to Pareto, that’s normal. At least 80% of the population, companies, and professionals will think this way. Great news for the other 20%: less competition.

The world was not made to be fair or equal. The real world is, by nature, highly unfair and unequal. In it, true heroes are battle-scarred, thick-skinned from taking so many hits, and they rise solely and exclusively through their own effort. The real world runs on meritocracy. Many will fool themselves for a while, thinking they’ve found a place that will stay stable and equal forever, but that period is temporary and doomed to disappear, replaced by a merit-based system that will crush them without mercy. Most people are terrified of that, terrified of losing their comfort zone.

All these cake recipes dressed up as self-help, masquerading as serious courses, are cheap mythology in homeopathic doses. I won’t describe them as anything more than what they really are. They all come loaded with “advice”, and the best definition of advice I’ve ever seen is in the famous Sunscreen video:

“Advice is a form of nostalgia. Dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than it’s worth.”

Campbell’s Heroes don’t live in the comfort zone: leaving the common path is the hero’s routine. The journey begins exactly when he decides to challenge what everyone else considers impossible. The hero becomes a myth when he conquers the impossible, and the impossible never yields to “normal” paths.

Myths are rare, unfortunately (or fortunately).