My brother organizes an entrepreneurship academy at the high school he principals. I play the role of technical advisor to teams that want to build apps. Last year’s team I advised won first place. This is the initial advice I’ve given:

When I talk to people about building apps I usually focus on two things:

1. Can you prove out the idea without building the app at all? In other words, use a combination of low-tech tools (spreadsheets, phone calls, emails, google survey, etc) to create your first 10 customer transactions. This is really helpful to understand your customers and it’s much easier to tweak your product idea early on. To learn more, look up “Lean Startup”.

2. Can you draw out how the app will work? Just using paper and pencil, you can draw out all of the screens. The best way to learn is to download a fresh app from the App Store (something you’ve never used before) and draw out the entire experience of a user. Try to recreate it on paper in such a way that you can explain to someone who has never seen the real app. To learn more, look up “Paper app prototyping”

Those are my top 2 most important things to do. For your business plan, I understand you’ll also need to have a solid budget and costs. I can’t tell you exactly how much your app would cost without knowing how complex it needs to be. The more time you can take in thinking through the details, the better prepared you’ll be when you take your concept to a local design and development agency.

I came up with this list to spark peer-led initiatives on an engineering team. Originally I used it to work with a team to define “ideal practice”, “current practice”, and then identify distinct “projects” to close the gap. The examples here are to help explain what I’m describing and are probably not the ideal state.

Frontend

Frontend engineering is unique because the engineer has relatively little control over the environment or human context in which their applications are run and used.

• Browser compatibility: Having a standard; reviewed regularly? Based on real user data from GA. SCSS Autoprefixer
• Real user monitoring (performance, bandwidth/api latency): using Fullstory and New Relic. Having a performance budget / SLO. Having “key transactions” for monitoring
• Browser exception monitoring: Sentry with sourcemaps
• Viewport / responsive design: Standards, device lab, browserstack assertions, etc.
• Usability: Heatmaps, User observation, Usability interviews, clear activation metrics, etc
• Accessibility: Accessibility Standards and Linting. People care about accessibility. Technical staff are proficient with Voiceover
• Customer interaction: Confidence and knowledge to have public conversations with customers and support them. Self-directed teams that understand the product well enough that they can take and manage customer feedback

Backend

The services that do the work.

• Services, Responsibilities and Boundaries: Monoliths, SOA, Microservices, how you slice the problem.
• Data storage: SQL/NoSQL, cache (Redis), index (ES, Solr), etc
• Database Querying: Getting the data, N+1s, Views, indexing
• Asynchronous Operations: job workers, notifications/messaging, ETLs, scheduled emails, generated reports

Development and Collaboration

A technically complex team sport.

• Packaging and build pipeline: Up-to-date build tooling. Containerized and artifacted, roll-backable, and promotable. Live code reloading. JS/CSS packaging
• Source code management and sharing: The source is committed to a Git repository and uploaded to GitHub. Code Review on PRs. File naming and organization conventions; practice of removing unused code.
• Dependency management: Dependencies are regularly updated. Considering breaking out things into modules. Having a standard for out-of-date updates. Dependency risk review (availability, security, do-we-need-it). Gemnasium, etc.
• API Design: Client systems (front and backend) have something to talk to. Available and complete documentation, messages attached to API calls should be coherent. Design is part of some standard process
• Continuous Integration: CI server; automated tests. Regularly review runtime. Regularly reviews and automates manual tasks
• Testing: Testing is easy. Visual regression. Acceptance testing as part of a team. Code coverage is tracked and managed.
• Philosophy of personal productivity: Automation vs just doing it. Consensus on that XKCD cartoon about how long something takes. “Maker hours” and review of happiness/productivity. Time tracking, etc.
• Philosophy of team productivity: Meetings and collaboration across departments and functions. Process for managing the process of change.

Project Management and Acceptance

Within complex systems - both human and technical - it’s difficult to ensure that the work being done is the right work to be done. On the business level, certain parts of the system, especially visual-facing, may unduly affect perception of the overall system.

• Management philosophy: Scrum, kanban, theory of constraints
• Management practice (running standup, demos, retros, architectural planning): Concise Agenda, Clear outcomes, well-facilitated. Come prepared. Meeting Templates. Clear reason why in and having the meeting
• Management tools (Jira, Trello, sticky notes): Visually track the flow of work through the organization
• Code and standards reviews: Enforce standards with automation. Regularly scheduled as part of project
• Collateral and hand-offs: Collab with Product, Design and Ops. Clear templates and cross-checks; Wire frames over pixel-perfect mockups.
• Acceptance and demos: Feature Flagging; Staging Environment. Standard handoff process.
• Estimating and Prediction: Have a high-level view of process. Be able to make and communicate estimates satisfactorily and/or accurately.
• Managing and prioritizing product feedback: Can receive feedback efficiently and route/evaluate/prioritize. Balances functions between Product, Design and Engineering.

Delivery and Operations

• Asset hosting and CDNs: Quick, reliable, and caches don’t ruin your day (“you’ll have to clear your cache”)
• Service monitoring (deliverability, consistency, verification): Healthchecks; SLO; Pagerduty; thresholds; frog boils.
• Security: https, XSS, Pentests, Bugbounties, responsible disclosure, Human/asset management
• Business Continuity: Backups, Domain name and certificate renewals, multi-datacenter, hit-by-a-bus problems
• Dependency and vulnerability management philosophy: Scheduling reviews/updates
• Incident Command and Management: Roles and responsibilities, SLAs, incident reporting, play/run-books
• Bugs and regression management: identification, prioritization, prevention
• Marketing/activity/metrics tracking: Practice (tag management) and Process (can easily report out biz analysis numbers without heroics)

Standardization and Innovation

Web engineering, as the intersection of several different domains and technologies (e.g. HTML, CSS, JavaScript, browsers, backends, PaaS, etc.) rapidly innovates along multiple dimensions. These are strategies for managing change.

• Frameworks (e.g. Rails) & conventions (e.g. BEM): Use open source community maintained framework/standards vs NIH; unique business case attitude
• Standards and style guides: Have coding practice/styleguides and ratification process
• Linting: Have coding practice/styleguides and ratification process
• Proof of Concepting: Be quicker to use to validate and overcome decision avoidance. Quantity of work that is thrown away.
• Architecture and system strategy: Long term technical vision and alignment with external forces and opportunities

Stewardship and Advancement

Ensure a healthy and growing environment exists for technical practitioners to professionally advance and spread the good news.

• Onboarding and orientation of new hires and practitioners
• Career advancement path
• Industry Leadership: public speaking, publishing, being a leader in the field

From Chris Hadfield’s An Astronaut’s Guide to Life on Earth: What Going to Space Taught Me About Ingenuity, Determination, and Being Prepared for Anything:

Occasionally the criticism is personal, though, and even when it’s constructive, it can sting. Prior to my last mission, my American crewmate Tom Marshburn and I were in the pool for a six-hour EVA evaluation, practicing spacewalking in front of a group of senior trainers and senior astronauts. Tom and I have both done EVAs in space and I thought we did really well in the pool. But in the debrief, after I’d explained my rationale for tethering my body in a particular way so I’d be stable enough to perform a repair, one of our instructors announced to the room, “When Chris talks, he has a very clear and authoritative manner—but don’t let yourself be lulled into a feeling of complete confidence that he’s right. Yes, he used to be a spacewalking instructor and evaluator and he’s Mr. EVA, but he hasn’t done a walk since 2001. There have been a lot of changes since then. I don’t want the junior trainers to ignore that little voice inside and not question something just because it’s being said with authority by someone who’s been here a long time.”

At first that struck me as a little insulting, because the message boiled down to this: “Mr. EVA” sounds like he knows what he’s doing, but really, he may not have a clue. Then I stopped to ask myself, “Why is the instructor saying that?” Pretty quickly I had to concede that the point was valid. I don’t come off as wishy-washy and I’m used to teaching others how to do things, so I can sound very sure of myself. That doesn’t mean I think I know everything there is to know; I’d always assumed that people understood that perfectly well and felt free to jump in and question my judgment. But maybe my demeanor was making that difficult. I decided to test that proposition: instead of waiting for feedback, I’d invite it and see what happened. After a sim, I began asking my trainers and crewmates, “How did I fall short, technically, and what changes could I make next time?” Not surprisingly, the answer was rarely, “Don’t change a thing, Chris—everything you do is perfect!” So the debrief did what it was supposed to: it alerted me to a subtle but important issue I was able to address in a way that ultimately improved our crew’s chances of success.

From “All Clear” by Connie Willis:

Polly had asked Mr. Goode to do the eulogy, remembering his sermon that day in Backbury. He spoke of [spoiler] and his bravery at Dunkirk and then said,

“We live in hope that the good we do here on earth will be rewarded in heaven. We also hope to win the war. We hope that right and goodness will triumph, and that when the war is won, we shall have a better world. And we work toward that end. We buy war bonds and put out incendiaries and knit stockings—”

And pumpkin-colored scarves, Polly thought.

“—and volunteer to take in evacuated children and work in hospitals and drive ambulances—”

Here Alf grinned and nudged Eileen sharply in the ribs.

“—and man anti-aircraft guns. We join the Home Guard and the ATS and the Civil Defence, but we cannot know whether the scrap metal we collect, the letter we write to a soldier, the vegetables we grow, will turn out in the end to have helped win the war or not. We act in faith.

“But the vital thing is that we act. We do not rely on hope alone, though hope is our bulwark, our light through dark days and darker nights. We also work, and fight, and endure, and it does not matter whether the part we play is large or small. The reason that God marks the fall of the sparrow is that he knows that it is as important to the world as the bulldog or the wolf. We all, all must do ‘our bit.’ For it is through our deeds that the war will be won, through our kindness and devotion and courage that we make that better world for which we long.

“So it is with heaven,” the vicar said. “By our deeds here on earth, in this world so far from the one we long for, we make heaven possible. We not only live in the hope of heaven but, by each doing our bit, we bring it to pass.”

From the introduction to “The Art of Focused Conversation”. There is a number of these kinds of arguments.

In Parallel Thinking, Edward de Bono says that Western culture has always esteemed critical thinking too highly. Teachers are always getting students to “react” critically to something put in front of them. The easiest kind of critical comment is a negative one. In a meeting or conversation, any person who wants to be involved or noticed has to say something. The easiest form of contribution is the negative. Criticism is also emotionally attractive and satisfying. When I attack an idea, I am instantly made superior to the idea or the originator of the idea. Criticism is also one of the few ways in which people who are not creative can achieve something and become influential.

Moreover, says de Bono, criticism takes very little effort. All you have to do is to choose a frame of judgement different from someone else’s and you have a free field of fire for your intellectual howitzers. If the conversation is about architecture, and someone is admiring the work of the Bauhaus style and I prefer imitation classical, I can simply point out that the Bauhaus is stark, lacking in grace, and downright boring. If someone is in favor of the whole-word approach to teaching reading, I can point out its lack of emphasis on phonetics. If the conversation ends there (as it usually does), I will never understand my friend’s sense of beauty which leads her to admire the Bauhaus style. I will never hear the teacher’s story of trial and error, as she sought to help children overcome their inner blocks to learning.

That, in brief, is the problem—criticism as the first step in a discussion stops the discussion and is therefore, generally the last step as well. It is an entirely different matter if I hear the other person first, understand what she is trying to do, then talk with her about better ways to do it. De Bono does point out that criticism is a valuable and essential part of thinking, but, of itself, totally inadequate. (de Bono, Parallel Thinking, pp. 27-28.)

An excerpt from the essay “Wrong—Again—About Plain Language” by Joseph Kimble; written in defense of Plain Language legislation and in response to an attacker:

Advocates believe that “it is more important to be clear . . . than to be accurate.”

This charge could not be more wrong. I responded to Mr. Stark on this same point 18 years ago.[14] No reputable advocate has ever said that clarity trumps accuracy. Yes, I have said, “Your main goal is to convey your ideas with the greatest possible clarity.”[15] But of course I mean “convey your ideas accurately.” Nobody who knows my work — or the work of any other advocate — could possibly think otherwise. We all take the need for accuracy as blindingly obvious.[16] But we do think that, with rare exceptions, clarity and accuracy are complementary — not competing — goals. As Reed Dickerson, the father of modern-day legal drafting, wryly put it: “The price of clarity, of course, is that the clearer the document the more obvious its substantive deficiencies.”[17] Or in the words of another expert: “The purposes of legislation are most likely to be expressed and communicated successfully by the drafter who is ardently concerned to write clearly and to be intelligible.”[18] Time after time, we have seen clarity improve accuracy by uncovering the ambiguities and errors that traditional drafting tends to hide. Yet if in some instance, on some point, accuracy and clarity really are at odds, then accuracy wins. It goes without saying — almost.

From “Secrets: A memoir of Vietnam and the Pentagon Papers” by Daniel Ellsberg:

“Henry [Kissinger], there’s something I would like to tell you, for what it’s worth, something I wish I had been told years ago. You’ve been a consultant for a long time, and you’ve dealt a great deal with top secret information. But you’re about to receive a whole slew of special clearances, maybe fifteen or twenty of them, that are higher than top secret.

“I’ve had a number of these myself, and I’ve known other people who have just acquired them, and I have a pretty good sense of what the effects of receiving these clearances are on a person who didn’t previously know they even existed. And the effects of reading the information that they will make available to you.

“First, you’ll be exhilarated by some of this new information, and by having it all – so much! incredible! – suddenly available to you. But second, almost as fast, you will feel like a fool for having studied, written, talked about these subjects, criticized and analyzed decisions made by presidents for years without having known of the existence of all this information, which presidents and others had and you didn’t, and which must have influenced their decisions in ways you couldn’t even guess. In particular, you’ll feel foolish for having literally rubbed shoulders for over a decade with some officials and consultants who did have access to all this information you didn’t know about and didn’t know they had, and you’ll be stunned that they kept that secret from you so well.

“You will feel like a fool, and that will last for about two weeks. Then, after you’ve started reading all this daily intelligence input and become used to using what amounts to whole libraries of hidden information, which is much more closely held than mere top secret data, you will forget there ever was a time when you didn’t have it, and you’ll be aware only of the fact that you have it now and most others don’t… and that all those other people are fools.

“Over a longer period of time – not too long, but a matter of two or three years – you’ll eventually become aware of the limitations of this information. There is a great deal that it doesn’t tell you, it’s often inaccurate, and it can lead you astray just as much as the New York Times can. But that takes a while to learn.

“In the meantime it will have become very hard for you to learn from anybody who doesn’t have these clearances. Because you’ll be thinking as you listen to them: ‘What could this man be telling me if he knew what I know? Would he be giving me the same advice, or would it totally change his predictions and recommendations?’ And that mental exercise is so torturous that after a while you give it up and just stop listening. I’ve seen this with my superiors, my colleagues… and with myself.

“You will deal with a person who doesn’t have those clearances only from the point of view of what you want him to believe and what impression you want him to go away with, since you’ll have to lie carefully to him about what you know. In effect, you will have to manipulate him. You’ll give up trying to assess what he has to say. The danger is, you become something like a moron. You’ll become incapable of learning from most people in the world, no matter how much experience they may have in their particular areas that may be much greater than yours.”

From The politics of Helen Keller: Socialism and disability by Keith Rosenthal:

For instance, in a groundbreaking article, “The Unemployed,” written in 1911 for a magazine for the blind Keller argued,

We have been accustomed to regard the unemployed deaf and blind as victims of their infirmities. That is to say, we have supposed that if their sight and hearing were miraculously restored, they would find work. But I wish to suggest to the readers of this article that the unemployment of the blind is only part of a greater problem.

Mass unemployment, Keller argued, is due not to “physical defects or lack of ability,” but rather to the fact that capitalist production requires “a large margin of idle men.” The capitalist class use the pressure of unemployment to force workers to compete with one another, and in that process, “the weaker workmen are thrust aside.” Thus, she argued, blindness may be a contributing factor to a person’s unemployment, but not the primary cause. Linking the struggle of blind people for the right to work with the struggle of all unemployed people for jobs, she wrote, “We know that the blind are not debarred from usefulness solely by their infirmity. Their idleness is caused by conditions which press heavily upon all working people.” She concluded that “it is not physical blindness, but social blindness which cheats our hands of their right to toil.”

[…]

Sadly, the fundamental dream that Helen Keller maintained throughout most of her life ultimately eluded the grasp of her generation. In the years since her death, that dream—the dream of a socialist world, free of oppression, exploitation, and war—has likewise been deferred for subsequent generations. And yet, that dream has not died, and will not die as long as there are people in the world who remain animated by the memories and legacies of Helen Keller and all of our other fighting ancestors. It is in such a spirit that this article ends at the beginning—with an excerpt from the very first public lecture given by Helen Keller, in February 1913.

I am going to try to make you feel that no one of us can do anything alone, that we are bound together. I do not like this world as it is. I am trying to make it a little more as I would like to have it.

It was the hands of others that made me. Without my teacher I should be nothing. Without you I should be nothing. We live by and for each other. We are all blind and deaf until our eyes are open to our fellow men. If we had penetrating vision we would not endure what we see in the world today.

The lands, the life, and the machinery belong to the few. All the work they do gains for the workers a mere livelihood. It is the labor of the poor and ignorant that makes others refined and comfortable. It is strange that we do not see it and that when we do we accept the conditions.

But I am no pessimist. The pessimist says that man was born in darkness and for death. I believe that man was intended for the light and shall not die. It is a good world and it will be much better when you help me to make it more as I want it.

Came across this quote from John Kenneth Galbraith in a presentation by L. Carson of the University of Sydney about Strategic Questioning (pdf):

Faced with the choice between changing one’s mind and proving that there is no need to do so, almost everyone gets busy on the proof.

From Sandi Metz’s “The Shape at the Bottom of All Things”:

I totally understand that this is a small example and that these techniques can feel like overkill for a problem of this size. Perhaps they are; I wouldn’t resist if you insisted it were so. However, there are bigger problems for which these techniques are the perfect solution and I rely on your ability to see the larger abstraction. You can’t choose whether to use these techniques unless you know them and it’s much easier practice on a small example like this.

From the Chapter 1 of Robert Martin’s Clean Code:

Consider this book a description of the Object Mentor [the group of authors of this book] School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and proessional. But don’t make the mistake of thinking that we are somehow “right” in any absolute sense. There are other schools and other masters that have just as much claim to professionalism as we. It would behoove you to learn from them as well.

Indeed, many of the recommendations in this book are controversial. You will probably not agree with all of them. You might violently disagree with some of them. That’s fine. We can’t claim final authority. On the other hand, the recommendations in this book are things that we have thought long and hard about. We have learned them through decades of experience and repeated trial and error. So Whether you agree or disagree, it would be a shame if you did not see, and respect, our point of view.