daviddoji/professional-programming
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
56c20ee269
professional-programming/README.md
Charles-Axel Dein 56c20ee269 Fix a few broken links
2019-11-29 14:31:09 +01:00

50 KiB
Raw Blame History

Table of Contents

Professional Programming

Give me six hours to chop down a tree and I will spend the first four sharpening the axe. (Abraham Lincoln)

A collection of full-stack resources for programmers.

The goal of this page is to make you a more proficient developer. You'll find only resources that I've found truly inspiring, or that have become timeless classics.

This page is not meant to be comprehensive. I am trying to keep it light and not too overwhelming. The selection of articles is opinionated.

Contributing to this list

Feel free to open a PR to contribute! I will not be adding everything: as stated above, I am trying to keep the list concise.

Must-read books

I've found these books incredibly inspiring:

There are some free books available, including:

Must-read articles

  • Practical Advice for New Software Engineers
  • On Being A Senior Engineer
  • Lessons Learned in Software Development: one of those articles that give you years of hard-earned lessons, all in one short article. Must read.
  • Things I Learnt The Hard Way
    • Spec first, then code
    • Tests make better APIs
    • Future thinking is future trashing
    • Documentation is a love letter to your future self
    • Sometimes, it's better to let the application crash than do nothing
    • Understand and stay away of cargo cult
    • "Right tool for the job" is just to push an agenda
    • Learn the basics functional programming
    • ALWAYS use timezones with your dates
    • ALWAYS use UTF-8
    • Create libraries
    • Learn to monitor
    • Explicit is better than implicit
    • Companies look for specialists but keep generalists longer
    • The best secure way to deal with user data is not to capture it
    • When it's time to stop, it's time to stop
    • You're responsible for the use of your code
    • Don't tell "It's done" when it's not
    • Pay attention on how people react to you
    • Beware of micro-aggressions
    • Keep a list of "Things I Don't Know"
  • Signs that you're a good programmer
  • Signs that you're a bad programmer
  • 7 absolute truths I unlearned as junior developer
    • Early in your career, you can learn 10x more in a supportive team in 1 year, than coding on your own
    • Every company has problems, every company has technical debt.
    • Being overly opinionated on topics you lack real-world experience with is pretty arrogant.
    • Many conference talks cover proof of concepts rather than real-world scenarios.
    • Dealing with legacy is completely normal.
    • Architecture is more important than nitpicking.
    • Focus on automation over documentation where appropriate.
    • Having some technical debt is healthy.
    • Senior engineers must develop many skills besides programming.
    • We’re all still junior in some areas.
  • How to Build Good Software
    • A good high-level summary of fundamental engineering practices.
    • The root cause of bad software has less to do with specific engineering choices, and more to do with how development projects are managed.
    • There is no such thing as platonically good engineering: it depends on your needs and the practical problems you encounter.
    • Software should be treated not as a static product, but as a living manifestation of the development team’s collective understanding.
    • Software projects rarely fail because they are too small; they fail because they get too big.
    • Beware of bureaucratic goals masquerading as problem statements. If our end goal is to make citizens’ lives better, we need to explicitly acknowledge the things that are making their lives worse.
    • Building software is not about avoiding failure; it is about strategically failing as fast as possible to get the information you need to build something good.

Other general material and list of resources

Courses

Topics

Algorithm and data structures

Let's be honest: algorithms can be a pretty dry topic. This quora question lists some funnier learning alternative, including:

API design

Attitude, habits, mindset

Automation

Biases

Biases don't only apply to hiring. For instance, the fundamental attribution bias also applies when criticizing somebody's code written a long time ago, in a totally different context.

Career growth

Characters sets

Coding & code quality

Computer science

Configuration

  • The downsides of JSON for config files, Martin Tournoij.
    • Can't add comments
    • Excessive quotation and syntax noise
    • Using DC (declarative configuration) to control logic is often not a good idea.

Databases

Data formats

Data science

Debugging

Design (visual, UX, UI)

I highly recommend reading The Non-Designer's Design Book. This is a pretty short book that will give you some very actionable design advices.

Articles :

  • 10 Usability Heuristics Every Designer Should Know
    • Visibility of System Status
    • The Match Between The System And The Real World
    • Every system should have a clear emergency exit
    • Don't forget that people spend 90% of their time interacting with other apps
    • Recognition Rather Than Recall (recognition = shallow form of retrieval from memory, e.g. a familiar person, recall = deeper retrieval)
    • ”Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” – Antoine de Saint-Exupery
    • Help Users Recognize, Diagnose, And Recover From Errors

Design (OO modeling, architecture, patterns, anti-patterns, etc.)

Here's a list of good books:

One of the absolute references on architecture is Martin Fowler: checkout his Software Architecture Guide.

Articles:

I maintain a list of antipatterns on another repo. This is a highly recommended read.

You can use an eraser on the drafting table or a sledge hammer on the construction site. (Frank Lloyd Wright)

Design: simplicity

  • Simple Made Easy 🎞, Rich Hickey. This is an incredibly inspiring talk redefining simplicity, ease and complexity, and showing that solutions that look easy may actually harm your design.

Dev environment & tools

Tools

Diversity & inclusion

Check out my list of management resources.

Documentation

Dotfiles

Articles

Editors & IDE

Engineering management

Checkout my list of management resources.

Exercises

The best way to learn is to learn by doing.

Incident response (alerting, outages, firefighting)

Internet

Interviewing

Note: this is about you as an interviewee, not as an interviewer. To check out my list of resources for interviewers, go to my engineering-management repository.

See also the exercises section in this document.

Learning & memorizing

Learn how to learn!

  • How I Rewired My Brain to Become Fluent in Math: subtitled the building blocks of understanding are memorization and repetition.
  • One Sure-Fire Way to Improve Your Coding: reading code!
  • Tips for learning programming
  • You can increase your intelligence: 5 ways to maximize your cognitive potential: forgive the clickbait title, it’s actually a good article.
  • How to ask good questions, Julia Evans.
  • Stop Learning Frameworks
  • Learning How to Learn: powerful mental tools to help you master tough subjects
  • Why books don’t work, Andy Matuschak.
    • "As a medium, books are surprisingly bad at conveying knowledge, and readers mostly don’t realize it."
    • "In learning sciences, we call this model “transmissionism.” It’s the notion that knowledge can be directly transmitted from teacher to student, like transcribing text from one page onto another. If only!"
    • "By re-testing yourself on material you’ve learned over expanding intervals, you can cheaply and reliably commit huge volumes of information to long-term memory."
  • Strategies, Tips, and Tricks for Anki: those advices work for any tool actually
    • Add images. Our brains are wired visually, so this helps retention.
    • Don't add things you don't understand.
    • Don't add cards memorizing entire lists.
    • Write it out. For wrong answers, I'll write it on paper. The act of writing is meditative. I really enjoy this.
    • Keep on asking yourself why? why does this work? why does it work this way? Force yourself to understand the root of a topic.
    • Cornell Method: when reading a topic, write out questions on the margins to quiz yourself.
    • Pretend you have to teach it
    • Use mnemonics phrases like PEMDAS for lists and other hard-to-remember topics.
    • Delete cards that don't make sense or you don't want to remember anymore.
  • Effective learning: Twenty rules of formulating knowledge
    • Build upon the basics
    • Stick to the minimum information principle: the material you learn must be formulated in as simple way as it is
    • Cloze deletion is easy and effective: Kaleida's mission was to create a ... It finally produced one, called Script X. But it took three years
    • Graphic deletion is as good as cloze deletion
    • Avoid sets
    • Avoid enumerations
    • Combat interference - even the simplest items can be completely intractable if they are similar to other items. Use examples, context cues, vivid illustrations, refer to emotions, and to your personal life
    • Personalize and provide examples - personalization might be the most effective way of building upon other memories. Your personal life is a gold mine of facts and events to refer to. As long as you build a collection for yourself, use personalization richly to build upon well established memories
    • Provide sources - sources help you manage the learning process, updating your knowledge, judging its reliability, or importance
    • Prioritize - effective learning is all about prioritizing.
  • How to Remember Anything You Really Want to Remember, Backed by Science
    • Quiz yourself
    • Summarize and share with someone else.
    • Connect what you just learned to experiences you previously had.

Richard Feynman's Learning Strategy:

  1. Step 1: Continually ask "Why?”
  2. Step 2: When you learn something, learn it to where you can explain it to a child.
  3. Step 3: Instead of arbitrarily memorizing things, look for the explanation that makes it obvious.

Most people overestimate what they can do in 1 year and underestimate what they can do in a decade. – Bill Gates

Frankly, though, I think most people can learn a lot more than they think they can. They sell themselves short without trying. One bit of advice: it is important to view knowledge as sort of a semantic tree — make sure you understand the fundamental principles, ie the trunk and big branches, before you get into the details/leaves or there is nothing for them to hang on to. — Elon Musk

"Experience is something you don't get until just after you need it." ― Steven Wright

Low-level

  • Back to Basics, Joel Spolsky. Explains why learning low level programming is important.
    • I think that some of the biggest mistakes people make even at the highest architectural levels come from having a weak or broken understanding of a few simple things at the very lowest levels.

Network

  • The Great Confusion About URIs
    • A URI is a string of characters that identifies a resource. Its syntax is <scheme>:<authority><path>?<query>#<fragment>, where only <scheme> and <path> are mandatory. URL and URN are URIs.
    • A URL is a string of characters that identifies a resource located on a computer network. Its syntax depends on its scheme. E.g. mailto:billg@microsoft.com.
    • A URN is a string of characters that uniquely identifies a resource. Its syntax is urn:<namespace identifier>:<namespace specific string>. E.g. urn:isbn:9780062301239

Problem solving

Project management

See Project management section on my engineering-management list of resources.

Programming languages

I would recommend learning:

  • JavaScript and maybe another interpreted language (Python, Ruby, etc.). Interpreted languages are useful for quick one-off automation scripts, and fastest to write for interviews. JavaScript is ubiquitous.
  • A compiled language (Java, C, C++...).
  • A more recent language to see where the industry is going (as of writing, Go, Swift, Rust, Elixir...).
  • A language that has first-class support for functional programming (Haskell, Scala, Clojure...).

A bit more reading:

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

-- Bjarne Stroustrup (C++ creator)

Python

For Python feel free to checkout my professional Python education repository.

JavaScript

JavaScript is such a pervasive language that it's almost required learning.

FP vs. OOP

  • Jargon from the functional programming world
  • Goodbye, Object Oriented Programming
  • Functional Programming & Haskell: some good reasons to learn FP!
  • Functional Programming Fundamentals: short introduction to FP and its advantages.
  • OO vs FP, Robert C. Martin, The Clean Code Blog. A pretty interesting take on the differences between OOP and FP from an expert in OOP.
    • OO is not about state. Objects are bags of functions, not bags of data.
    • Functional Programs, like OO Programs, are composed of functions that operate on data.
    • FP imposes discipline upon assignment.
    • OO imposes discipline on function pointers.
    • The principles of software design still apply, regardless of your programming style. The fact that you’ve decided to use a language that doesn’t have an assignment operator does not mean that you can ignore the Single Responsibility Principle.

Over-engineering

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.”

John Gall, General systemantics, an essay on how systems work, and especially how they fail..., 1975 (this quote is sometime referred as "Galls' law")

"Software engineering is what happens to programming when you add time and other programmers."

Rob Pike, Go at Google: Language Design in the Service of Software Engineering

Reading

  • Papers we love: papers from the computer science community to read and discuss. Can be a good source of inspiration of solving your design problems.
  • The morning paper: one CS research paper explained every morning.

Releasing & deploying

Security

Shell

System architecture

Scalability

  • I already mentioned the book Scalability rules above, but there's also a presentation about it.

Stability

  • I already mentioned the book Release it! above. There's also a presentation from the author.

Resiliency

Site Reliability Engineering (SRE)

Books:

  • Site Reliability Engineering 📖
    • Written by members of Google's SRE team, with a comprehensive analysis of the entire software lifecycle - how to build, deploy, monitor, and maintain large scale systems.

Articles:

Technical debt

Testing

Tools

Version control (Git)

Work ethics, productivity & work/life balance

Web development

Writing

  • Undervalued Software Engineering Skills: Writing Well
    • From the HN discussion: "Writing a couple of pages of design docs or an Amazon-style 6 pager or whatever might take a few days of work, but can save weeks or more of wasted implementation time when you realise your system design was flawed or it doesn't address any real user needs."

Writing for performance

Concepts

Glossary