This is a book born of mistakes, of failures - my own and others - of paths trodden that are better left alone, and of tidbits of wisdom that, I hope, will help you reach your goals faster and with less regret. Also: empathy is the best productivity hack, which I’ll explain later.
It’s not exclusively a coding book - it’s an “everything else” book so that when you do write code, you’re solving the right problems at the right time and in the right way for that specific context.
I have no credentials to offer, but programming language design and related philosophies have been my special interest for 22 years. I’ve been creating and shipping projects solo since I was a wee thing, and I have read tens of millions of lines of code.
Full transparency: I’m going to use AI to autocomplete the hell out of this. I read 800-1000 wpm and type under 80. Asking the right questions and validating the result is what matters.
Another disclaimer: Every person should calibrate their planning philosophy to account for the cognitive load situation of themselves and their team. Being continuously aware of implications can have a negative effect on productivity, so think about what you think about. I believe that load diminishes with exercise, though, and the net benefit can be excellent.
As you plan and code, let your mind become accustomed to thinking in multiple roles -
-
As an attacker, how could I exploit this design to steal resources or take down the system? What’s the worst way this API or app could be misused?
-
As a devops person, how hard will this be to maintain, patch, deploy, backup/restore, and support?
-
As someone who is blind or color-blind or hearing-impaired, how would I access this and what would that be like?
-
As someone who has a busy life but also has very slow wifi, would I be patient enough to use this?
-
As a new person who has to come in and change this code, how well does the code communicate the problem being solved?
-
Is this going to harm others or the planet? Software guides behavior and changes society, and humans think in terms of their tools.
Higher-level thinking is also important when you have influence over project management:
-
As someone in charge of business decisions, is this problem worth solving at this point in time?
-
As someone in charge of disaster recovery, What is the potential cost of incorrect data here? Can we eliminate human error? Can we brute-force test the result space?
-
As a responsible party, could this cause legal risk?
-
Can we slightly shift our expectations to reuse something that already exists?
I'm creating a book targeted at people who have a computer science degree or similar but need to fill in the blanks quickly - learning from other people's mistakes - to be ready for a high-productivity, high-value career in the industry. It needs to be funny, engaging, and readable. But above all, correct and insightful.
-
Reuse: Share a vocabulary, Code as Communication, Seek Standards, locate OSS.
-
Ask: Asking the right questions of people, and of the code. Code is communication.
-
Secure: Think like an attacker, always
-
Test: Establishing invariants so you can kayak after work
-
Exceptional: Evaluate edge cases habitually.
-
Time: How much time to spend and when
-
Value: Do what matters
-
Mind: Manage cognitive load by choosing what to drop from your awareness
-
Joy: Avoid burn-out and push for better DX than you think you need.
-
Context: When to toss the rules out the window, and when to play it safe
-
Law: Staying legal requires study
-
Harm: Speaking up or walking away
-
Appendix
Informal, first and second person, direct and succinct, examples and tidbits first, cautionary tales included. The author is naturally too systematic and robotic in her tech writing and needs the assistance of AI to come off as human, please oblige, many thanks!
As a teenager, I had terrible internet, and one particular set of dropped bytes turned me into lifelong snowboarding addict. In fact, I had absolutely no role in downloading the entire client database of the ski resort. It... simply appeared on my screen.
While you could shrug this off as incompetence of the aughts, this category of mistake is still made at the biggest companies on the regular. And with the downturn in MVC use and resurgence of full-stack symmetrical frameworks and WASM, it's likely on the uptick.
In this instance, a hidden field was used to store state - specifically whether the user was an admin or a visitor. And if your browser sent off an incomplete HTTP request, without that field data, you got a 20MB+ table back with much more than your own profile data.
I immediately contacted the webmaster, informed him of the vulnerability and offered to help. My family shredded free for a couple years (we wouldn't have otherwise), and I put in a few hours to shore their security up slightly.
If there's one crucial thing that new web developers need to put focus into, it's awareness of where the backend and frontend boundary should lie.
When you put data filtering, query parameter selection, or authorization in client code, it might not even take a hacker to discover it; it might just take a bad internet connection.
The frontend — the client — can never be trusted.
Get developer interest, introduce quick bite anecdotes of catastrophic communication failures or humor or xkcd link. Introduce code as communication, shared vocabulary importance, value of standards. Cohesive theory of invariants, cognitive load, and how use of shared code, concepts, and standards makes life easier.
[ChatGPT insert draft here]
Define a guideline for comparing github activity recency, commit count, issue count, and package consumption metrics to estimate real-world usage.
Concise guide to jumping into a git repository in any language and knowing where to look in what order to trace the shape of the repo or monorepo.