A collection of full-stack resources for programmers.

Related tags

Miscellaneous programming-language learning computer-science documentation architecture concepts scalability professional programmer engineer read-articles lessons-learned
Overview

Table of Contents

Professional Programming - about this list

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.

Items:

  • 🧰 : list of resources
  • 📖 : book
  • 🎞 : video/movie extract/movie
  • 🏙 : slides/presentation

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

List of axioms:

  • Precepts - Urbit
    • Data is better than code.
    • Correctness is more important than performance.
    • Deterministic beats heuristic.
    • One hundred lines of simplicity is better than twenty lines of complexity.
    • If your abstractions are leaking, it's not due to some law of the universe; you just suck at abstracting. Usually, you didn't specify the abstraction narrowly enough.
    • If you avoid changing a section of code for fear of awakening the demons therein, you are living in fear. If you stay in the comfortable confines of the small section of the code you wrote or know well, you will never write legendary code. All code was written by humans and can be mastered by humans.
    • If there's clearly a right way to do something and a wrong way, do it the right way. Coding requires incredible discipline.
    • The best way to get the right answer is to try it the wrong way.
    • Practice tells you that things are good or bad; theory tells you why.
    • Not being qualified to solve a problem is no reason not to solve it.
    • If you don't understand a system you're using, you don't control it. If nobody understands the system, the system is in control.
  • Embedded Rules of Thumb
  • 50 Ideas That Changed My Life

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:

Example implementations:

API design & development

Attitude, habits, mindset

  • Mastering Programming, Kent Beck.
  • The traits of a proficient programmer
  • The tao of programming: a set of parables about programming.
  • Taking Ownership Is The Most Effective Way to Get What You Want
  • Finding Time to Become a Better Developer
  • Ten minutes a day: how Alex Allain wrote a book in less than 200 hours, by writing 10 minutes every day.
  • The care and feeding of software engineers (or, why engineers are grumpy)
    • In the triumvirate of software, product managers, designers, and software engineers, only the engineers are expected to turn off their creative minds and just produce.
    • Both engineers and product managers tend to think, incorrectly, that product specifications or requirements are equivalent to the furniture manual from Ikea.
    • This is one of the top things that make engineers grumpy: constantly shifting priorities.
    • Even though many engineers will complain that product managers change their minds, almost none will account for that in their time estimates.
    • Computer science programs aren’t about preparing you for the tasks you’ll face in industry.
    • When there are more engineers than can be used, engineering time ends up going away from developing and towards planning, synchronization, and coordination.
    • Involve engineers in the creative process
    • Give engineers opportunities to be creative.
    • Encourage time off.
    • Let 'em code
    • Express appreciation
  • The Product-Minded Software Engineer, Gergely Orosz
    • Great product engineers know that minimum lovable products need the right depth
    • Product-minded engineers quickly map out edge cases and think of ways to reduce work on them: often bringing solutions that require no engineering work
    • Engage in user research and customer support
    • Bring well-backed product suggestions to the table
    • Offer product/engineering tradeoffs
  • 40 Lessons From 40 Years, Steve Schlafman
    • If you want to make progress on the things that matter most, you need to decide who you’re going to disappoint. It’s inevitable.
    • The best investment you can make is your own education. Never stop learning. The second best investment you can make is building your network through authentic and meaningful interactions. It is what you know and who you know.
    • You’ll never get what you don’t ask for or actively seek out. Go for it!
    • It’s not about the light at the end of the tunnel. It’s the tunnel. Show up every day and enjoy the process.
    • A great teammate always puts the organization and its purpose ahead of their own self interests.
    • Pick your spots. We have limited time and our brains can only process so much. Focus is key. Choose wisely.
    • Every person is likely struggling with something. Be kind. Be helpful.
  • On Coding, Ego and Attention
    • Beginner’s mind accepts the fact that absolute knowledge is infinite and thus keeping score is a waste of time.
    • Mastery is simply the accumulation of momentum, not the accumulation of knowledge.
    • Dealing with ego distraction has taught me to love the problem solving process. It’s taught me to love and respect the learning process. As a result I’m more productive. I’m less anxious. I’m a better teammate. I’m a better friend and a better thinker.
  • Fixed vs. Growth: The Two Basic Mindsets That Shape Our Lives
  • What does a great software engineer look like?
  • Good sleep, good learning, good life
  • 🎞 Steve Jobs: if you don't ask for help, you won't get very far

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

Code reviews

  • How to do a code review, Google's engineering practices documentation.
  • Post-Commit Reviews: an interesting idea to increase developer velocity (there are some caveats though).
  • How to Make Your Code Reviewer Fall in Love with You
    • Review your own code first
    • Write a clear changelist description
    • Automate the easy stuff
    • Answer questions with the code itself
    • Narrowly scope changes
    • Separate functional and non-functional changes
    • Respond graciously to critiques
    • Artfully solicit missing information
    • Award all ties to your reviewer
    • Minimize lag between rounds of review

Coding & code quality

Computer science

Configuration

Databases

Exercises:

Data formats

Data science/data engineering

Debugging

Design (visual, UX, UI, typography)

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 :

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:

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

Design: database schema

  • A humble guide to database schema design, Mike Alche
    • Use at least third normal form
    • Create a last line of defense with constraints
    • Never store full addresses in a single field
    • Never store firstname and lastname in the same field
    • Establish conventions for table and field names.

Design: patterns

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.

Practice:

Hardware

  • NandGame: build a computer from scratch.

Incident response (oncall, alerting, outages, firefighting, postmortem)

  • Incident Response at Heroku
  • My Philosophy On Alerting
    • Pages should be urgent, important, actionable, and real.
    • Err on the side of removing noisy alerts – over-monitoring is a harder problem to solve than under-monitoring.
    • Symptoms are a better way to capture more problems more comprehensively and robustly with less effort.
    • Include cause-based information in symptom-based pages or on dashboards, but avoid alerting directly on causes.
    • The further up your serving stack you go, the more distinct problems you catch in a single rule. But don’t go so far you can’t sufficiently distinguish what’s going on.
    • If you want a quiet oncall rotation, it’s imperative to have a system for dealing with things that need timely response, but are not imminently critical.
  • The Google SRE book's chapter about oncall
  • Writing Runbook Documentation When You’re An SRE
    • Playbooks “reduce stress, the mean time to repair (MTTR), and the risk of human error.”
    • Using a template can be beneficial because starting from a blank document is incredibly hard.
    • The Curse of Knowledge is a cognitive bias that occurs when someone is communicating with others and unknowingly assumes the level of knowledge of the people they are communicating with.
    • Make your content easy to glance over.
    • If a script is longer than a single line, treat it like code, and check it into a repository to be source control and potentially tested.

Postmortem

Dan Milstein, “Let’s plan for a future where we’re all as stupid as we are today.”

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.
  • How To Remember Anything Forever-ish: a comic about learning

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, assembly

  • 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.
  • What's in a Linux executable?

Network

  • The Great Confusion About URIs
    • A URI is a string of characters that identifies a resource. Its syntax is :?#, where only and 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:[email protected].
    • A URN is a string of characters that uniquely identifies a resource. Its syntax is urn::. E.g. urn:isbn:9780062301239

Observability (monitoring, logging, exception handling)

Logging

  • Do not log dwells on some logging antipatterns.
    • Logging does not make much sense in monitoring and error tracking. Use better tools instead: error and business monitorings with alerts, versioning, event sourcing.
    • Logging adds significant complexity to your architecture. And it requires more testing. Use architecture patterns that will make logging an explicit part of your contracts
    • Logging is a whole infrastructure subsystem on its own. And quite a complex one. You will have to maintain it or to outsource this job to existing logging services
  • Lies My Parents Told Me (About Logs)
    • Logs are cheap
    • I can run it better myself
    • Leveled logging is a great way to separate information
    • Logs are basically the same as events
    • A standard logging format is good enough
  • Logging - OWASP Cheat Sheet Series

Error/exception handling

Monitoring

Perspective

Problem solving

Project management

See the 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.

Functional programming

  • 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.
  • Parse, don’t validate
    • Use a data structure that makes illegal states unrepresentable
    • Push the burden of proof upward as far as possible, but no further
    • Let your datatypes inform your code, don’t let your code control your datatypes
    • Don’t be afraid to parse data in multiple passes
    • Avoid denormalized representations of data, especially if it’s mutable
    • Use abstract datatypes to make validators “look like” parsers

Programming paradigm

  • Imperative vs Declarative Programming, Tyler McGinnis.
    • I draw the line between declarative and non-declarative at whether you can trace the code as it runs. Regex is 100% declarative, as it’s untraceable while the pattern is being executed.

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.

Refactoring

  • The Rule of Three, Coding Horror
    • Every programmer ever born thinks whatever idea just popped out of their head into their editor is the most generalized, most flexible, most one-size-fits all solution that has ever been conceived.
    • It is three times as difficult to build reusable components as single use components.
    • A reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.
  • Refactor vs. Rewrite
  • Tripping over the potholes in too many libraries

Releasing & deploying

  • How We Release So Frequently
  • How to deploy software, Zach Holman
  • BlueGreenDeployment, Martin Fowler
  • Move fast and break nothing, Zach Holman
  • Flipping out, flickr. One of the first articles about feature flags.
  • Production Readiness Checklist, Gruntwork
  • Checklist: what had to be done before deploying microservices to production
  • Things end users care about but programmers don't: includes colors, formatting, themes, integrations, UX, compatibility, operations.
  • Feature Flags, Toggles, Controls, a website documenting feature flags, from Launch Darkly.
  • Feature Toggles (aka Feature Flags), Pete Hodgson, martinFowler.com. Comprehensive article on the topic.
    • Deliver new functionality to users rapidly but safely
    • Release Toggles allow incomplete and un-tested codepaths to be shipped to production as latent code which may never be turned on.
    • Experiment Toggles are used to perform multivariate or A/B testing.
    • Ops Toggles control operational aspects of our system's behavior.
    • Permissioning Toggles change the features or product experience that certain users receive.
    • Static vs dynamic toggles
    • Long-lived toggles vs transient toggles
    • Savvy teams view their Feature Toggles as inventory which comes with a carrying cost, and work to keep that inventory as low as possible.
  • Feature Flags Best Practices: Release Management, LaunchDarkly
  • Developing in Production
    • Complex systems have emergent behavior, producing epiphenomenon that only appears with sufficient scale.
    • Wood's theorem: As the complexity of a system increases, the accuracy of any single agent’s own model of that system decreases rapidly.
    • The more tools and code that you add to create elements in a system, the harder it is to replicate an environment encompassing those tools and code.
    • At the core of testing in production is the idea of splitting deployments (of artifacts) from releases (of features).
  • Testing in Production: the hard parts, Cindy Sridharan
    • The whole point of [actual] distributed systems engineering is you assume you’re going to fail at some point in time and you design the system in such a way that the damage, at each point is minimized, that recovery is quick, and that the risk is acceptably balanced with cost.
    • How can you cut the blast radius for a similar event in half?
      • Differentiate between deployment (0 risk) and release
      • Build a deploy-observe-release pipeline
      • Make incremental rollouts the norm (canaries, %-based rollouts, etc.)
      • Test configuration changes just like you test code
      • Default to roll back, avoid fixing forward (slow!)
      • Eliminate gray failures - prefer crashing to degrading in certain cases
      • Prefer loosely coupled services at the expense of latency or correctness
      • Use poison tasters (isolate handling of client input)
      • Implement per-request-class backpressure
      • Have proper visibility from a client/end-user standpoint (client-side metrics)
  • Testing in Production, the safe way
  • Why We Leverage Multi-tenancy in Uber's Microservice Architecture

Security

List of resources:

Shell (command line)

System administration

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.

Reliability

  • How Complex Systems Fail
    • Catastrophe requires multiple failures – single point failures are not enough.
    • Complex systems contain changing mixtures of failures latent within them.
    • Post-accident attribution to a ‘root cause’ is fundamentally wrong.
    • Hindsight biases post-accident assessments of human performance.
    • Safety is a characteristic of systems and not of their components
    • Failure free operations require experience with failure.

Resiliency

Site Reliability Engineering (SRE)

Note: this section is only about SRE as a role. Checkout the System Architecture for more content related to reliability.

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:

Reliability is the one feature every customer users. -- An auth0 SRE.

Resources:

Technical debt

  • TechnicalDebt, Martin Fowler.
  • Fixing Technical Debt with an Engineering Allocation Framework
    • You don't need to stop shipping features to fix technical debt
    • Communicate the business value
  • Ur-Technical Debt
    • Today, any code that a developer dislikes is branded as technical debt.
    • Ward Cunningham invented the debt metaphor to explain to his manager that building iteratively gave them working code faster, much like borrowing money to start a project, but that it was essential to keep paying down the debt, otherwise the interest payments would grind the project to a halt.
    • Ur-technical debt is generally not detectable by static analysis.

Testing

Tools

Version control (Git)

Work ethics, productivity & work/life balance

  • Your non-linear problem of 90% utilization, Jason Cohen: why constantly running at 90% utilization is actually counter-productive.
  • Evidence-based advice on how to be successful in any jobs: most self-help advices are not research-based. The ones listed in this article are.
  • The Complete Guide to Deep Work
    • The ability to perform deep work is becoming increasingly rare at exactly the same time it is becoming increasingly valuable in our economy.
    • Choose Your Deep Work Strategy
    • Build a Deep Work Routine
    • Discipline #1: Focus on the Wildly Important
    • Discipline #2: Act on the Lead Measures
    • Discipline #4: Create a Cadence of Accountability
    • Our Ability for Deep Work is Finite
    • The Craftsman Approach to Tool Selection
    • Stop Using Social Media
    • Get Your Boss on Board With Deep Work
  • Every productivity thought I've ever had, as concisely as possible
    • Context intentionality as the key difference between home and every other place on planet earth
    • Rules are about exceptions
  • Makers, Don't Let Yourself Be Forced Into the 'Manager Schedule'
    • Research shows that it takes as long as 30 minutes for makers to get into the flow
    • Use maker-manager office hours
    • Communication can happen at a quieter asynchronous frequency in the form of thoughtful, written discussions rather than soul-sucking meetings or erratic one-line-at-a-time chat messages
    • Build a team knowledge base to minimize repetitive questions and allow self-onboarding.
  • Zettelkasten Method
  • 100 Tips for a Better Life
    • Deficiencies do not make you special. The older you get, the more your inability to cook will be a red flag for people.
    • History remembers those who got to market first. Getting your creation out into the world is more important than getting it perfect.
    • Discipline is superior to motivation. The former can be trained, the latter is fleeting. You won’t be able to accomplish great things if you’re only relying on motivation.
    • You do not live in a video game. There are no pop-up warnings if you’re about to do something foolish, or if you’ve been going in the wrong direction for too long. You have to create your own warnings.
    • Cultivate a reputation for being dependable. Good reputations are valuable because they’re rare (easily destroyed and hard to rebuild). You don’t have to brew the most amazing coffee if your customers know the coffee will always be hot.
    • Compliment people more. Many people have trouble thinking of themselves as smart, or pretty, or kind, unless told by someone else. You can help them out.

Web development

Writing (communication, blogging)

➡️ See also my engineering-management list

  • 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."
  • Sell Yourself Sell Your Work
    • If you've done great work, if you've produced superb software or fixed a fault with an aeroplane or investigated a problem, without telling anyone you may as well not have bothered.
  • The Writing Well Handbook
    • Ideas — Identify what to write about
    • First Drafts — Generate insights on your topic
    • Rewriting — Rewrite for clarity, intrigue, and succinctness
    • Style — Rewrite for style and flow
    • Practicing — Improve as a writer

Write like an Amazonian

Writing for performance

Resources & inspiration for presentations

Concepts

Glossary

Comments
  • python tkinter 累加累減程式

    python tkinter 累加累減程式

    def add(): for i in range(1,101): sum+=i result1.set('累加結果為:'+sum) def sub(): for i in range(100,0,-1): sum-=i result1.set('累減結果為:'+sum) import tkinter result1=tkinter.StringVar() win=tkinter.Tk() win.title('累加累減程式') win.geometry('500x500') label=tkinter.Label(win,text='累加累減程式',fg='red') label.pack() frame1=tkinter.Frame(win) frame1.pack() button1=tkinter.Button(frame1,text='+',command=add) button1.grid(row=0,column=0) button2=tkinter.Button(frame1,text='-',command=sub) button2.grid(row=0,column=1) result=tkinter.Label(win,textvariable=result1,fg='red') result.pack() win.mainloop()

    結果發生錯誤: Traceback (most recent call last):

    File "", line 1, in runfile('C:/Users/user/Desktop/加減程式.py', wdir='C:/Users/user/Desktop')

    File "C:\Users\user\Anaconda3\envs\py35\lib\site-packages\spyder\utils\site\sitecustomize.py", line 705, in runfile execfile(filename, namespace)

    File "C:\Users\user\Anaconda3\envs\py35\lib\site-packages\spyder\utils\site\sitecustomize.py", line 102, in execfile exec(compile(f.read(), filename, 'exec'), namespace)

    File "C:/Users/user/Desktop/加減程式.py", line 10, in result1=tkinter.StringVar()

    File "C:\Users\user\Anaconda3\envs\py35\lib\tkinter_init_.py", line 334, in init Variable.init(self, master, value, name)

    File "C:\Users\user\Anaconda3\envs\py35\lib\tkinter_init_.py", line 233, in init self._root = master._root()

    AttributeError: 'NoneType' object has no attribute '_root'

    opened by Lin0904 6
  • Adding a book

    Adding a book

    I added a book about Algorithms named "Introduction to Algorithms" by by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein.

    opened by nyilynnhtwe 2
  • Update README.md: remove duplicates within the same section/category

    Update README.md: remove duplicates within the same section/category

    👋😀 Besides these two, there are a few more duplicated links throughout the README but in different sections/categories:

    • amazon.com/The-Linux-Programming-Interface-Handbook/dp/1593272200
    • en.wikipedia.org/wiki/Domain-driven_design
    • github.com/charlax/dotfiles/tree/master/vim
    • github.com/charlax/engineering-management
    • github.com/jwasham/coding-interview-university
    • github.com/kdeldycke/awesome-falsehood
    • highscalability.com/
    • smile.amazon.com/Scalability-Rules-Principles-Scaling-Sites/dp/013443160X

    Maybe they should be cleaned up as well?

    opened by nelup20 2
  • adding link to the resilience engineering notes

    adding link to the resilience engineering notes

    Resilience engineering notes is a very useful collection of information about research, ideas and people involved in resilience engineering. It's worth a read for someone who is interested in this topic.

    opened by prasaadk 2
  • Added Game Programming Patterns

    Added Game Programming Patterns

    I figured this would be a good fit. The book goes over design, sequencing, behavioral, decoupling, and optimization patterns and uses game development as the medium to express the ideas. The patterns described are widely used and the book has been really helpful to me. It also helps that you can read it for free online.

    opened by bosley 1
  • my first 10 minutes on a server primer for securing ubuntu is unavailable

    my first 10 minutes on a server primer for securing ubuntu is unavailable

    I suggest you to use the gist https://gist.github.com/SimplGy/7dc513c725219b08e4632a09686f945d It contains all command lines described in the blog, unfortunately unavailable.

    opened by maathor 1
Owner
Charles-Axel Dein
Scaling teams, product and tech at GensDeConfiance. Previous experiences: Uber, faberNovel
Charles-Axel Dein
GitHub
4Geeks Academy Full-Stack Developer program final project.

Final Project Chavi, Clara y Pablo 4Geeks Academy Full-Stack Developer program final project. Authors Javier Manteca - Coding - chavisam Clara Rojano

null 1 Feb 5, 2022
PDX Code Guild Full Stack Python Bootcamp starting 2022/02/28

Class Liger Rough Timeline Weeks 1, 2, 3, 4: Python Weeks 5, 6, 7, 8: HTML/CSS/Flask Weeks 9, 10, 11: Javascript Weeks 12, 13, 14, 15: Django Weeks 16

PDX Code Guild 5 Jul 5, 2022
Participants of Bertelsmann Technology Scholarship created an awesome list of resources and they want to share it with the world, if you find illegal resources please report to us and we will remove.

Participants of Bertelsmann Technology Scholarship created an awesome list of resources and they want to share it with the world, if you find illegal

Wissem Marzouki 29 Nov 28, 2022
A simple language for new programmers and a toy language ;)

Yell An extremely simple, yet powerful language for new programmers, as well as a toy language ;) Explore the docs » Report Bug · Request Feature Yell

Yell 4 Dec 28, 2021
A collection of online resources to help you on your Tech journey.

Everything Tech Resources & Projects About The Project Coming from an engineering background and looking to up skill yourself on a new field can be di

Mohamed A 396 Dec 31, 2022
Collection of script & resources for Foundry's Nuke software.

Author: Liam Collod. Collections of scripting stuff I wrote for Foundry's Nuke software. Utilisation You can have a look at the README.md file in each

Liam Collod 1 May 14, 2022
Python with the scientific stack, compiled to WebAssembly.

Pyodide may be used in any context where you want to run Python inside a web browser.

null 9.5k Jan 9, 2023
51AC8 is a stack based golfing / esolang that I am trying to make.

51AC8 is a stack based golfing / esolang that I am trying to make.

null 7 May 22, 2022
Stack BOF Protection Bypass Techniques

Stack Buffer Overflow - Protection Bypass Techniques

ommadawn46 18 Dec 28, 2022
vFuzzer is a tool developed for fuzzing buffer overflows, For now, It can be used for fuzzing plain vanilla stack based buffer overflows

vFuzzer vFuzzer is a tool developed for fuzzing buffer overflows, For now, It can be used for fuzzing plain vanilla stack based buffer overflows, The

Vedant Bhalgama 5 Nov 12, 2022
Plock : A stack based programming language

Plock : A stack based programming language

null 1 Oct 25, 2021
jonny is a stack based programming language

jonny-lang jonny is a stack based programming language also compiling jonny files currently doesnt work on windows you can probably compile jonny file

null 1 Nov 24, 2021
Morth - Stack Based Programming Language

Morth WARNING! THIS LANGUAGE IS A WORKING PROGRESS. THIS IS JUST A HOBBY PROJECT

Dominik Danner 2 Mar 5, 2022
A simple assembly- and brainfuck-inspired stack-based language

asm-stackfuck A simple assembly- and brainfuck-inspired stack-based language. The language has a few goals: Be stack-based Look like assembly Have a s

Nils Trinity 1 Feb 6, 2022
One destination for all the developer's learning resources.

DevResources One destination for all the developer's learning resources. Find all of your learning resources under one roof and add your own. Live ✨ Y

Gaurav Sharma 33 Oct 21, 2022
Inspect the resources of your android projects and understand which ones are not being used and could potentially be removed.

Android Resources Checker What This program will inspect the resources of your app and help you understand which ones are not being used and could pot

Fábio Carballo 39 Feb 8, 2022
A repository containing useful resources needed to complete the SUSE Scholarship Challenge #UdacitySUSEScholars #poweredbySUSE

SUSE-udacity-cloud-native-scholarship A repository containing useful resources needed to complete the SUSE Scholarship Challenge #UdacitySUSEScholars

Nandini Proothi 11 Dec 2, 2021
Resources for the 2021 offering of COMP 598

comp598-2021 Resources for the 2021 offering of COMP 598 General submission instructions Important Please read these instructions located in the corre

Derek Ruths 23 May 18, 2022
An ongoing curated list of frameworks, libraries, learning tutorials, software and resources in Python Language.

Python Development Welcome to the world of Python. An ongoing curated list of frameworks, libraries, learning tutorials, software and resources in Pyt

Paul Veillard 2 Dec 24, 2021