Pyramid vs. obelisk

I may not be able to save the world, but I think I’ve come up with the fundamental idea that will be necessary in order to restore (and, afterward, preserve) the integrity of, at the very least, the software industry.

Software may or may not be “eating the world”, but we’re learning that the class of people who can rigorously solve problems using precise thought is one that ought to be held in high demand. Such people need not necessarily be writing software programs per se, but we’re in a world that cannot grow based on ego and bluster (the traditional traits used to select business leaders) alone. That approach has been played out, and we need competence to get any further. There are a variety of literacies that a leader needs in order to do her job well, and that set of needed capacities is too large for me to tackle right now, so let’s zero in on one important job, which is software engineering. As a society, we need it. We need it, done well. Unfortunately, as a society, we seem to be getting worse at it.

The problem is that most of the people who employ programmers have seen fit, over the past two decades, to diminish this kind of work as much as possible. There have been so many efforts to replace professional programmers with interchangeable, unqualified peons that it is, frankly, sickening. This is, of course, the real purpose of the “Agile Scrum” fad that has infested our industry, as well as the fetishism for open-plan offices. Dan Lyons’s new book, Disrupted, describes the ageist culture that emerges when we allow the industry to drive software, rather than the other way around. We’ve seen competent engineers driven out in favor of cheap, young, and (most importantly) obedient commodity-grade programmers hired to inflate headcount numbers and appease investors. It needs to stop, and now, before this industry gets so thoroughly infested with incompetence and anti-intellectualism that a generation’s worth of work and experience will need to be discarded. So how do we stop it?

Although it shouldn’t be this way, software engineering is pyramidal in shape. For every engineer who gets to work on a real project, there seem to be fifteen grunts only trusted to churn through Jira tickets. We need to reform our professional structure to be more like an obelisk, instead.

Architecturally, a pyramid is the most basic, inefficient way of achieving prominence (or, less pedantically, height). It’s imposing, it’s gigantic, and it historically required massive amounts of slave labor as well as natural resources. Ancient Egyptians built pyramids because they didn’t have the architectural know-how (namely, arches) to build much else at scale. In economics, one invokes the pyramidal shape when describing arrangements that deliver massive yield to the few (at the top of the pyramid) while exploiting the larger lower classes (at the bottom). Hence, the term “pyramid scheme”. One could argue that pyramids (of both kinds) are entropic. A pile of sand or stones will assume an approximately conical shape, and it’s likely that this inspired the (architecturally unsophisticated) pyramids of Ancient Egypt. Likewise, an ill-organized or disorganized set of people will devolve into an oligarchic arrangement, with many supporting the few.

Professional pyramids mean that positional scarcity will exist at every level in the profession (the term “profession”, here, used loosely) as the number of positions declines as an exponential function of experience. It’ll be as hard to stay in the profession as to get in. Except for sociopaths who enjoy social competition for its own sake, most people find this undesirable. Doctors and attorneys wouldn’t be happy if they had to continue fighting for fewer spots with each year of age, even 30 years after graduating. Not only would it be bad for individuals to have that degree of positional competition, but it would also be a waste for society. To push out 50-year-old doctors simply because they “failed” to arrogate managerial positions would be to discard hard-won expertise, and it would generate a culture of inexperience.

Left to their own devices, management hierarchies become pyramidal. If a company of 10,000 people decides on a 12:1 reporting ratio (as is typical, in software) then it’s going to have 9,167 grunts, 764 first-level managers, 64 directors (managers of managers), and only 5 people at the executive level as traditionally defined. Why can’t there be 100 directors instead of 64? There could be, but few companies would want to pay for them if given the choice. That pyramid seems painful, and it would be, if that’s how companies worked. At the top, they often don’t, and I’ve written before about the superior collective intelligence of MBAs as opposed to software programmers. People with elite MBAs aren’t stupid. They realize that they’re going to get screwed under the traditional pyramidal regime. Not only does the pyramid system make it unlikely for people to advance, but they also leave the people in high positions unprotected, because there are too few of them. CEOs promote loyalists not because the companies need so many executives, but because the CEOs are smart enough to realize that sharing rank and prominence is essential for their own survival.

One could argue that business executives, as a group, “conspire” against their companies by working together in order to convince their organizations that they’re more needed than they really are, and that more of them are needed than really are, and that they themselves as a class (executives) can recognize talent in a way that no one else (not shareholders, not workers) can. By doing this, they’ve managed to create massive demand for themselves and their skill set (which is perceived to be more rare than it actually is). On this topic, I’m hesitant to use the word “conspire” because I don’t consider it morally wrong. Corporate life has become a culture of resource extraction, and the executives have simply been the best players at that game. Ultimately, there are very few people who would hesitate, if offered a magical device that would imbue in their employers an extreme and superstitious overvaluation of their work, to use it for personal benefit. Executives have simply managed to do exactly that as a group, rather than as individuals, the latter being far more difficult.

Corporate executives, based on manufactured demand, as well as doctors and attorneys based on actual demand, have taken their leverage and replaced the pyramidal structure with a professional obelisk shape. An obelisk is upright, rising far higher than a pyramid of comparable mass could, until the pinnacle. With a professional obelisk, there’s plenty of room to grow until one encounters positional scarcity. Doctors don’t need to beat down other doctors and climb management hierarchies just to advance; they just need to gain more skills and deliver more value. Likewise, MBA-toting corporate executives might face stiff competition if they want to be Fortune-500 CEOs (because there are only 500 such spots) but they deal with minimal competition if they just want 7-figure incomes and fancy titles by age 50.

An obelisk structure shows that a value is placed on expertise: as long as people continue to improve themselves, there’ll be room for them at a level higher than where they are. Progress will be recognized. Why does the medical profession intentionally create an obelisk-shaped, guild structure? It doesn’t want “Agile” 17-year-olds performing surgery and driving out competent surgeons who didn’t pursue management jobs. It also doesn’t want people taking obscene risks due to an up-or-out culture that persists into one’s 40s and 50s. Finally, it doesn’t want a culture where the median practitioner has less than a decade of experience.

The pyramid is the entropic formation. Without a deliberate professional structure, it will emerge. Why so? An unprotected “profession” (note the oxymoron) will expand until it absorbs the most unqualified people, who draw barely more compensation than they’d get anywhere else, but who are able enough to convince people (unqualified buyers) to buy their services that they can stay afloat. The unqualified and minimally invested (the “quacks”) will, by sheer numbers, outvote the genuine practitioners (who’ve often dedicated their lives to becoming good at something) and dominate the culture– until their incompetence starts hurting people. In medicine and law, this outcome is considered so unacceptable that it’s not controversial for these industries to have professional structures that function as labor cartels. We need to start thinking the same way about software. We need to start driving out the charlatan brogrammers for whom the infantilizing open-plan startup culture was created.

So how do we get an obelisk-shaped, protected profession for software engineers?

Let’s focus on something that hasn’t worked, and look at why it has failed. Many companies have created “engineering ladders” that purport to measure professional development for individual contributors and allow people to grow without becoming managers. There might be a manager-equivalent title (Staff Engineer) and a Director-equivalent one (Principal Engineer, or Architect) and a VP-equivalent one (Fellow). What goes wrong? To start, the disparity in difficulty makes the whole thing extremely self-congratulatory on the part of the managers.

To become a Director- or VP-equivalent engineer, you have to compete against some of the smartest people in the company. It’s legitimately difficult. There are smart, qualified people who don’t make it. If anything, these dual-track systems serve the interests of management by allowing the executives to overstate their value and capability relative to engineers; if one has to be a genuinely great engineer to become Director-equivalent, the thinking is, then engineers will hold Directors and VPs on the much-easier-to-climb managerial tracks in higher regard.

Ultimately, these systems don’t work. Rather, they serve to document and justify an existing pyramidal scarcity. The organization will only allow a small number of engineers to climb into positions with the credibility and compensation afforded to senior managers, because engineers lack the collective organizational skill to thwart the penny-pinching game being played against them. Thus, a pyramid forms, and little is solved, because positional scarcity persists at each level.

I’ve been around for long enough to know that trusting employers is not a strategy. In the long term, it always fails. Don’t get me wrong: there are good companies out there, and there are managerial strategies (e.g. open allocation) that can improve the odds of creating one. Some individual employers probably can be trusted, but this doesn’t scale, because most organizations become pathological and self-serving at some point. So, if we can’t trust employers, then we can’t put stock in employer-assigned titles as a way to insure the credibility of the individual programmer. That means that we need an employer-independent system for doing so. We need a source of credibility for the individual that no employer can touch.

Doctors and attorneys have employer-independent credibility, being vouched-for by their professional associations (in the U.S., the AMA and the ABA). That’s necessary because the core of a profession is that one’s ethical obligations supersede managerial authority. That is, a doctor can’t use the superior orders defense to justify killing a patient. Of course, that only works if the professional has some sort of employer-independent credibility– in which case, losing a job is a transient financial annoyance rather than a possible career killer. If the individual lives entirely on his reputation as made by prior managers, his lack of leverage becomes a lack of moral agency. That is, of course, the problem that most programmers face. We lack moral or even creative autonomy, because we lack employer-independent credibility; once we leave school, our value is derived from the titles and recognitions given to us by profit-seeking corporations.

Some programmers hoped that the open-source world would fill this gap. It can’t. That’s not its job. Evaluating a programmer’s Github profile is a subjective task, and the only objective way of measuring one’s open-source contributions is based on how many people use the software. Here’s the issue, though. Few engineers have the time and resources available not only to build usable open-source projects, but to market their work to the global programming community enough that it actually used, and then to support it once it is. The positional scarcity and power-law distribution of open-source prominence emerge not because the open-source community is full of mean people (it’s not) but because (a) there’s no barrier to entry when it comes to just putting code out there, while (b) most of this code will never be used, because people have an entirely understandable (and, in fact, prudent) aversion to using unproven software.

How do we create an employer-independent credibility for software engineers? As far as I can tell, there are two solutions. The first is one that I hate: to require formal, institutional education. I hate it because it’s hostile to career-switchers, astronomically expensive, and can generate a culture of anti-intellectual credentialism. This leaves the second, which is to create an exam-based system, similar to what the actuarial sciences use. As programmers pass more exams, their professional credibility can grow in an employer-independent way. This would not only give us job security, but the improvement in our general leverage would enable us to negotiate for better working conditions and launch better projects, to the benefit of society as a whole.

Are there problems with exams? Of course there are. For one thing, I happen to believe that “bad test taker” is a real thing. (I was always a good test taker, but I’ve met intelligent people who aren’t.) We’d have to adapt our system to legitimate learning disabilities and to allow project-based alternatives for great programmers who struggle with traditional exams. We’d need to decide what to charge for the exams (as well as the presumably more expensive project evaluation) and how to offer financial aid. We’d have to decide what would be on the exams, and how many there would be. (I, personally, doubt that I’d be qualified to design such a curriculum.) What is an Associate-level programmer, and what’s a Fellow-level engineer, and what do we expect each to know? What are the continuing education requirements going to look like? These aren’t easy problems to solve. On the contrary, they’re quite difficult and organizationally complex.

Here’s the thing, about that. Designing a curriculum and exam track for software engineers is a massive amount of work, much of it ugly. I doubt I’m up to it, personally, because I’d rather have it built by experts in their respective fields of computer science. However, the core idea is here is one that will actually work. Blindly trusting employers hasn’t worked, and fetishizing startups has been a hilarious failure. Over the past twenty years, the programming profession has lost ground. We’ve been infantilized with open-plan offices and “Agile Scrum” practices that senior engineers don’t need. We’ve been left without any form of employer-independent credibility, which is what we’ll need if we want to become a true profession. We’re in a state of squalid failure. Our professional shape is a pyramid rather than an obelisk, making the job painfully political at every level. I’d rather see an imperfect solution (such as a professional curriculum and an employer-independent, exam-based advancement system) that fixes this than no solution at all. This problem won’t be solved by one person and it certainly won’t be solved within a year, but I’m confident that I know, at least, where to start.

30 thoughts on “Pyramid vs. obelisk

  1. Let’s not forget the vast asteroid belt of project managers that surround the programmers. I am not sure what they get paid but they certainly seem to exist in great numbers.

    Instead of 9,167 grunts, you might have 7,500 grunts, and 1,000 project managers, and maybe two levels of management between the director and the grunts.

    Often the lowest level of management, the most clueless of the Clueless, may actually be making barely more than the grunts.

  2. This is brilliant. These are ideas you’ve explained before (mostly), but this is a really good structure of explanation.

    I have some hope for things like StarFighter – “exams” structured like Capture The Flag exercises, conducted primarily through coding. But yeah, designing the curriculum is really hard.

    One of the advantages of this formulation, and of the exam solution, is that it doesn’t have to be introduced all at once. Having a ladder of levels from associate through fellow is, as you say, very hard. But you can introduce levels one at a time and, to some extent, see what sticks.

    In some ways, it’s harder if you have a professional credentialing organization that aims to be comprehensive. They’ll want to solve too much up-front. One nice thing about the existing commercial/private attempts at this (StarFighter, but also things like Aline Lerner’s interviewing.io) is that they can try some things and see what works. This is an area that will require a lot of experimentation.

  3. If the managerial obelisk doesn’t have an “exam” based promotion and ranking then why should the engineers need one.

    To achieve your goals; what you really need is for the SEC to require all public companies that deal with networked data to have a practicing engineer on the board to help prevent security issues or danger to the public. This forces the CEO to respect the desires of the engineer since board members have the power to threaten their position as CEO. With all the stolen credit data now is the ripe time to push that legislation. At very least PCI compliance should require it.

  4. The medical and legal credential systems don’t lend doctors and lawyers credibility that you don’t have as a software engineer, they’re just a barrier to entry, much as a B.S. degree is in software engineering. They don’t say whether you’re good at your job or worth hiring.

    You have the same employer-independent credibility as any doctor. It’s your skills (and connections, and height, etc). Surgeons that don’t keep up their skills don’t get the better job they want, they lose out to someone more qualified (or better connected, or taller) just like you do.

    I think you’re wrong to claim pyramidal or dual-track systems “don’t work” — you realize every company has an org chart that is roughly pyramid shaped, right? Sure, many of them are too “top heavy” with an absurd amount of VP’s. But the fact is VP level jobs are necessary. Maybe you’ve never worked at a company where the big shots couldn’t provide enough direction but it’s really awful and a lot of money gets wasted. Leadership is a hugely important skill and one I don’t recall you writing on much. It’s needed at every level but especially at the top.

    I find flatter organizations more pleasant to work in but they just don’t scale to a 500+ company.

  5. There’s already a couple of exams were aiming for similar goals and have met with a overwhelming lack of interest from both employers and developers:

    – The IEEE Certified Software Development Professional now deprecated and now replaced with a handful of IEEE professional competency certifications for developers and software engineers:
    https://www.computer.org/web/education/certifications/
    https://www.computer.org/web/education/professional-competency-certifications

    – Professional Licensure (i.e., Professional Engineer) – It is now possible to become a licensed software engineer in the same way that, say, civil engineers can. You have to pass the PE exam (Principles and Practice of Engineering Examination for software) as well as the Fundamentals of Engineering exam. I’ve seen very little interest in this. Understandably since the Fundamentals exam covers ‘chemistry, physics, mechanics (i.e. statics and dynamics), materials science, computer science, electronics/circuits, engineering design, and the standard range of engineering mathematics (i.e. calculus, differential equations, statistics)’, and that’s a lot of unrelated or marginally related work for most developers to do. But I suspect that even without that friction, there would be little interest.

    I am unfortunately pessimistic about this approach. Businesses have little to gain (in their eyes) by supporting/demanding/rewarding it), and developers have seemingly little interest.

    Keep up the thoughts though. We need a solution. Unionizing of course in could in theory be an effective solution. But it has next-to-no chance of succeeding (though I think that its chances are greater than that of an external credential). Too many tech mythology (such as about meritocracy) has successfully hypnotized people, and there’s too much ego. And of course Wal Mart’s union-busting efforts would look like a charity event compared to what the tech industry would unleash should unionizing ever somehow become an actual threat.

    • I remember a pitch from the dean of engineering towards the end of college to get a P.E. license. It made no sense. Maybe it’s more desired in some parts of industry I have no connections with (defense?) but I’ve looked at easily 2000 resumes over the years and never seen a P.E. mentioned.

      • Agreed. A quick look at LinkedIn shows that there may be a grand total of 1 on LinkedIn. Not a thorough search, but they are certainly not common.

    • I pitched professionalization to some of my friends, including manager friends. Approximately zero interest. One of them was a manager at a game company and had aggressively no interest in any education, even though he has a CS degree himself. He basically just wanted to hire genius cowboys (and then burn through them with death marches, though that was more a consequence of how the game industry works).

      I still think a profession is the right approach though. As a profession with exams by our own society, we would take some control of what is important rather than just obeying universities or providing a smorgasboard of skills for employers. For instance, hiring is so vastly inefficient and stupid that there has to be a better way and the CS/IT educational system should hang its head in shame. Would hospitals really need to start hiring by checking that their new doc can write a basic prescription?

      Other things in its favor: socialize us introverts to not be so damn naive, and perhaps provide some way to limit the MBA damage. For instance, lawyers have some rule that they can only be managed by lawyers. Well, why not work for the same in our field?

      So I think there are advantages, but as mentioned before, actually doing it is not so straightforward. An exam shouldn’t descend to technology tests, for example, because those rot so quickly. And it probably shouldn’t be an engineering exam either, because those have a different focus. And one might ask whether there should be just plain ‘developer’ or more specialization (but in that case, who has the time or money for a million little degrees?). So … some issues remain to be addressed.

    • How do you not throw people under the bus? By not throwing people (developer or otherwise) under the bus.

      The implicit us (developers) vs them (management, HR, VC’s, etc) mindset of Mr. Church’s writings is something he really needs to work on.

        • Why is the us vs them mindset incorrect? Look, the whole point of having a company is to accomplish things that will make the company (and by extension, the employees) money. Companies get ugly and political when groups of people view each other as the enemy. This leads to inefficiencies that lower productivity and bring in less money. Every part of the company has a function. You may not understand what exactly a senior VP of accounting does all day but that doesn’t mean that job function isn’t valuable, all it means is you don’t know what he does.

          • Meat Donut, I agree with what you say. But in it also lies a conundrum. I would argue that the predominant worldview of much business leadership already has an us-vs-them mentality toward developers: thinkers vs doers, value-add vs fungible resources, white collar vs blue collar, privileged vs unprivileged, entitled vs eternal required proving of credibility.

            Taking the high road means that developers automatically lose. Not acknowledging the context means continued exploitation and double standards. Pretending that an us-vs-them mentality doesn’t exist in cases where it already does doesn’t mean that it doesn’t exist.

            Thoughts? How do you see a meaningful change happening while engaging on an uneven playing field?

            • I think you’re attacking a straw man. Using words like exploitation in the context of developers to me is ludicrous. We’re well paid and hugely in demand. If you’re being “exploited” right now you are an idiot.

              There are some bad companies out there that you don’t want to work for. This is true of any industry and job function. You may not believe this, but MBA’s can have bad experiences with their jobs just like you can. I’ve worked at 8 companies and the majority were very positive experiences. That doesn’t come for free, you’ve got to be wise about who you work for and move on when it’s not in your interest to stay.

              • It’s definitely true that there is a wide variance in employers (and also a wide variance within many companies). I have a different viewpoint on developer exploitation than you do however.

                Do you believe that all developers at Google, Apple, Adobe and Intel were all idiots because their employers illegally conspired to keep their wages low? And that all developers required to do Scrum are idiots for not quitting their jobs since Scrum has very few responsibilities or deliverables for Product Owners and very specific ones for the Development team? And in addition, the Product Owner can require the Development Team to do *all* of his or her work according to the official Scrum Guide (“The Product Owner may do the above work, or have the Development Team do it”). That these idiots are responsible for this context?

                In my opinion, these fall within common definitions of exploitation:
                “The action or fact of treating someone unfairly in order to benefit from their work”
                “The act of employing to the greatest possible advantage”
                “Utilization of another person or group for selfish purposes”

    • One thing: When manager comes snooping around asking “How is doing?”, answer “He’s doing a fine job”, and stick to that story.

      At one job that went badly, it was clear my boss was going around asking everyone for complaints about me.

  6. I believe that a more effective approach is simply to shine light on MBAs and subtly ridicule them. Their world is starting to crumble. It’s a slow crumbling, but MBAs, business schools, and 20th century mindsets are losing credibility. It will take a generation, but we will see the time when being an MBA is a liability and is cause for automatic suspicion.

    People can’t articulate it yet, but the unease with the architects of the financial crisis, the political elite, and privileged sinecures in the workplace will ultimately point to several places – including both MBAs and the Ivy League.

    This goes much larger than just developers. It’s even larger than makers and takers. A healthier workplace is emerging, just barely emerging from its seed and poking out of the ground.

  7. On many of the software development teams I’ve worked on, everyone was better than everyone else at everything.

    We tend to love to talk about how MBA types are such assholes, but we can be pretty big assholes ourselves – impatient, rude, judgemental, superficial, and eager to pin differences in opinion on other people’s incompetence. And God help you if one of these people makes it into management – with a few exceptions, they add paranoia, secrecy, and vindictiveness onto their delightful list of qualities. After all, machines that work predictably are good, so people who are in any way unpredictable are bad … and stupid, and useless, and brain-damaged, and …

    I’ll take a vapid MBA over one of these robots any day. In fact, I started my own business specifically because I am sick of people like this infecting my life.

    And I don’t think that is the result of some conspiracy by businesspeople – I think, because we take so little interest in other people, we’re all naturally like that to some degree. Business just worked with what it had. The solution? Something that technical people understand – rules, the rules that MOC laid out – no ratting out to upper management, no expressions of feigned surprise, no holy wars over which brand-name language to use … basic mutual respect that is a right, not a privilege.

    • No, no, no, it’s all those other kinds of people’s fault, not us developer-angels.

      In the words of the famous philosopher Zapp Brannigan: “We know nothing about them, their language, their history or what they look like. But we can assume this. They stand for everything we don’t stand for. Also they told me you guys look like dorks.”

    • I don’t disagree, but I don’t think that faults in one group of people means that problems with a different group of people shouldn’t be discussed. Let’s discuss and try to address both.

      I would also add that there are problably structural incentives for developers to snipe at each other. The fact is that in most business situations, developers have less positional or role power and thus can only effectively snipe at or about other low status individuals.
      To act as if that problems with developers aren’t *also* affected by structural concerns and organizational incentives isn’t realistic IMO.

      • Of course we are structurally incentivized to act this way. We work in noisy, distracting environments, under meaningless deadlines, often punished for failure and seldom rewarded for success. My point is that this structure formed when business realized it could take advantage of our natural contentiousness to extract huge amounts of value. And of course they would do this – they were acting in (what seemed to be) their own interests, just as it is in our interest to protect ourselves by recognizing that we have these problems, and developing a widely accepted code of conduct to counter it. You can’t fight directly against business – but what you can do is quietly refuse to cooperate with their divide-and-conquer tactics. What are they going to do, fire you because you didn’t call a coworker incompetent when they were building their case? I’ve given up on office life, but it doesn’t mean others can’t continue the fight.

        • True words. But not cooperating with divide-and-conquer tactics basically just means that you don’t lose any further than you already have… it’s not a win but a lack of further loss. That’s worth something, but I’m at the point where I want to ‘fight’ back and have been… mostly to the gain of some local optimization at the expense of a sore forehead.

          • Local optimizations are always good. I say this seriously and without sarcasm – if you come up with an effective tactic to fight back please let me know. I’m off the grid, but it doesn’t mean I’m not bitter about my experiences, and it doesn’t mean I don’t want to see things change.

    • Let me second this a thousand items. It’s true that management guards what they say at all times and works together to forward their own interests, which I respect. While each and every programmer out there considers him or herself the one and only exception to the adage “no man is an island” for each considers him or herself the smartest guy in the room bar none. I am so tired of programmer infighting over who knows more about this or that totally irrelevant BS. Everyone is willing to sell everyone else out at a moments notice: it’s no wonder so many engineers have a fetish for Ayn Rand, in their own minds every one of them is Atlas, carrying the weight of the entire company/team/org/startup on their shoulders. It’s enough to drive a reasonable self effacing human being to drink!

      The funny part being that for those who prefer technology to humanity precisely because the former obeys regular predictable rules (that can be reliably gamed), there is only one option to get them the remuneration their efforts actually deserve. That would be strong arming them using intimidation to join a professional organization with enough power to cripple employers who won’t play ball. Just call it the Spacing guild, there are enough who simply couldn’t resist joining a sci-if cult made real… And build from there using the once great and powerful Rob Hubbard’s well known and highly effective playbook.

  8. I come from the Software Craftsman (note the singular) persuasion.

    Software is the only Engineering where Design is the Product, where Prototype is the finish, where project requirements are the end-result. There are no manufacturing factories, no assembly line workers, no grand designers and hence no managers required at all to build fully functioning Software.

    Markus Frind of Penty Of Fish fame demonstrates this beautifully.

    What I look forward in the future is for the Industry to move past this infantile phase of us-vs-them and to look at all software, legitimately, as Dancing Architecture,

    • You’re fighting against an entire economy attempting to commodify your efforts. No one except some fellow developers care about Software Craftsmanship. All they want to know if (usually in this order) how much will it cost and when will I get it? Your products are a commodity to them in the same way that a purchased shirt it to you. Chances are that you aren’t thinking of artistic stitching, fabric sourcing, etc. To your average employer, you’re just a ‘vendor’ and a bad vendor at that: very expensive, difficult to understand, and with a confusing culture (where things such as Dancing Architecture are spoken of and are valued).

  9. Pingback: “Doctors and attorneys have employer-independent credibility, being… | Roy Schestowitz - API Key Placeholder

  10. Pingback: Links 10/4/2016: MATE 1.14, LibreOffice 5.1.2 | Techrights

  11. Although a profession would scale better and faster than a category, I still think some sort of funding groups like Category you mentioned months ago would be worth building. It could complement a profession to prevent organizations from becoming pyramidal in shape. A category blurs distinction between investor, worker, and manager, so it would be more suited to retain open allocation than traditional corporations.

    The combination of a co-operative funding group(like category) and a profession could be a huge boost to technologists.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s