Programming Professional Learning 2022

byACSNET • • 2 min read
0

 If you are seeking for true Sources to learn Programing, this's the Best Article that will show you the most important sources and will Lead you to the Perfect details.

    Learning Programing 



    Table of Contents:

    • Professional Programming - about this list
    • Contributing to this list
    • Must-read books
    • Must-read articles
    • Other general material and list of resources
    • Courses
    • Topics
    • Algorithm and data structures
    • API design & development
    • Attitude, habits, mindset
    • Automation
    • Biases
    • Career growth
    • Characters sets
    • Code reviews
    • Coding & code quality
    • Computer science
    • Configuration
    • Databases
    • Data formats
    • Data science
    • Debugging
    • Design (visual, UX, UI, typography)
    • Design (OO modelling, architecture, patterns, anti-patterns, etc.)
    • Design: the database schema
    • Design: patterns
    • Design: simplicity
    • Dev environment & tools
    • Diversity & inclusion
    • Documentation
    • Dotfiles
    • Editors & IDE
    • Engineering management
    • Exercises
    • Incident response (on-call, alerting, outages, firefighting, postmortem)
    • Postmortem
    • Internet
    • Interviewing
    • Learning & memorizing
    • Low-level
    • Network
    • Observability (monitoring, logging, exception handling)
    • Logging
    • Error/exception handling
    • Monitoring
    • Perspective
    • Problem-solving
    • Project management
    • Programming languages
    • Python
    • JavaScript
    • Functional programming
    • Programming paradigm
    • Over-engineering
    • Reading
    • Refactoring
    • Releasing & deploying
    • Security
    • Shell (command line)
    • System administration
    • System architecture
    • Scalability
    • Stability
    • Resiliency
    • Site Reliability Engineering (SRE)
    • Technical debt
    • Testing
    • Tools
    • Version control (Git)
    • Work ethics, productivity & work/life balance
    • Web development
    • Writing (communication)
    • Writing for performance
    • Resources & inspiration for presentations
    • Concepts
    Professional Programming - about this list
    • 🧰: list of resources
    • 📖: book
    • 🎞: video/movie extract/movie
    • 🎤: slides/presentation

    Contributing to this list:

    Must-read books
    • 📖 Release It!: this book goes beyond code and gives you best practices for building production-ready software. It will give you about 3 years worth of real-world experience.
    • 📖 Structure and interpretation of Computer Programs (free): One of the most influential textbooks in Computer Science (written and used at MIT), SICP has been influential in CS education. Byte recommended SICP "for professional programmers who are really interested in their profession". >
    • 📖 Professional software development: pretty complete and a good companion to this page. The free chapters are mostly focused on software development processes: design, testing, code writing, etc. - and not so much about the tech itself.

    Must-read articles:

    • 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 from cargo cult
    • "Right tool for the job" is just to push an agenda
    • Learn the basics of 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 to 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 a 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, and 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.
    • 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
    • The Imposter's Handbook - $30. From the author: "Don't have a CS Degree? Neither do I - That's why I wrote this book."
    • Data is better than code.
    • Correctness is more important than performance.
    • Deterministic beats heuristic.
    • One hundred lines of simplicity are 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

    Courses:

    Topics:

    Algorithm and data structures
    • Read the CLRS. You can watch and download the course on OCW - there are newer courses as well.
    API design & development
    • "Using links instead of foreign keys to express relationships in APIs reduces the amount of information a client needs to know to use an API and reduces the ways in which clients and servers are coupled to each other."
    Attitude, habits, mindset
    • Ten minutes a day: how Alex Allain wrote a book in less than 200 hours, by writing 10 minutes every day.
    • 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 the 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
    • 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
    • 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.
    • A 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.

    Automation:

    Biases:

    Career growth
    • A career is a marathon, not a sprint
    • Most success comes from repetition, not new things
    • If work was really so great all the rich people would have the jobs
    • Management is about people, not things
    • Genuinely listen to others
    • Recognize that staff are people with the finite emotional capacity
    • Don’t just network with people your own age
    • Never sacrifice personal ethics for a work reason
    • Recognize that failure is learning
    • Don’t focus too much on long-term plans.
    • Find good thinkers and cold-call the ones you most admire.
    • Assign a high value to productivity over your whole lifespan.
    • Don’t over-optimize things that aren’t your top priority.
    • Read a lot, and read things that people around you aren’t reading.
    • Reflect seriously on what problem to prioritize solving.
    • Read more history.
    Characters sets
    Code reviews
    • Post-Commit Reviews: an interesting idea to increase developer velocity (there are some caveats though).
    Coding & code quality
    • We’re tired of writing crap.
    • We will not accept the stupid old lie about cleaning things up later.
    • We will not believe the claim that quick means dirty.
    • We will not allow anyone to force us to behave unprofessionally.
    • There is a convention to prefix boolean variables and function names with "is" or "has".
    • Try to always use it, even for plurals (isEachUserLoggedIn is better than areUsersLoggedIn or isUsersLoggedIn)
    • Avoid custom prefixes (isPaidFor is better than wasPaidFor)
    • Avoid negatives (isEnabled is better than isDisabled)
    Computer science
    Configuration
    • Can't add comments
    • Excessive quotation and syntax noise
    • Using DC (declarative configuration) to control logic is often not a good idea.
    • Most modern config formats suck
    • Use a real programming language
    Databases
    Data formats
    Data science
    Debugging
    Design (visual, UX, UI, typography)
    • Book recommendations from HackerNews
    • 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 modelling, architecture, patterns, anti-patterns, etc.)
    • Education of a Programmer: a developer's thoughts after 35 years in the industry. There's a particularly good section about design & complexity (see "the end to end argument", "layering and componentization").
    • Complexity and Strategy: an interesting perspective on complexity and flexibility with really good examples (e.g. Google Apps Suite vs. Microsoft Office).
    Design: the database schema
    • Use at least a third normal form
    • Create a last line of defense with constraints
    • Never store full addresses in a single field
    • Never store first name and last name in the same field
    • Establish conventions for table and field names.
    Design: patterns
    • Build all the back-end code, and integrate, but don't build the user-interface
    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
    • htop: an interactive process viewer for Linux
    Diversity & inclusion
    Documentation
    Dotfiles
    Editors & IDE
    Engineering management
    Exercises
    • Challenging projects every programmer should try: text editor, space invaders, compiler (Tiny Basic), mini OS, spreadsheet, video game console emulator.
    Incident response (on-call, alerting, outages, firefighting, postmortem) >
    • 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 that you can’t sufficiently distinguish what’s going on.
    • If you want a quiet on-call rotation, it’s imperative to have a system for dealing with things that need a timely response, but are not imminently critical.
    • Playbooks “reduce stress, the meantime 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 controlled and potentially tested.
    Postmortem
    Internet
    Interviewing
    • I spent 3 months applying for jobs after a coding Bootcamp. Here’s what I learned.
    • Tech Interview Handbook
    Learning & memorizing
    • How I Rewired My Brain to Become Fluent in Math: subtitled the building blocks of understanding are memorization and repetition.
    • Learning How to Learn: Powerful mental tools to help you master tough subjects >
    • "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 to another. If only!"
    • "By re-testing yourself on the material you’ve learned over expanding intervals, you can cheaply and reliably commit huge volumes of information to long-term memory."
    • 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 them 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 in 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.
    • Build upon the basics
    • Stick to the minimum information principle: the material you learn must be formulated in an 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, and 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, update your knowledge, judge its reliability, or importance
    • Prioritize - effective learning is all about prioritizing.
    • Quiz yourself
    • Summarize and share with someone else.
    • Connect what you just learned to experiences you previously had.
    1. Step 1: Continually ask "Why?”
    1. Step 2: When you learn something, learn it to where you can explain it to a child.
    1. Step 3: Instead of arbitrarily memorizing things, look for the explanation that makes it obvious.
    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
    • 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
    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 monitoring with alerts, versioning, and 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 outsource this job to existing logging services
    • 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 >
    Error/exception handling
    Monitoring
    • From the Google SRE book: Latency, Traffic, Errors, and Saturation
    • USE Method (from Brendan Gregg): Utilization, Saturation, and Errors
    • RED Method (from Tom Wilkie): Rate, Errors, and Duration
    Perspective
    • The first is the importance of gratitude.
    • Second, a life, if lived well, is long enough.
    • Third, it’s important to let yourself be vulnerable and connect to others.
    • Fourth, do something for others.
    • Fifth, protect the planet.
    Problem-solving
    • Define the problem - what is it that you're trying to achieve?
    • Invert it - what would guarantee the failure to achieve this outcome?
    • Finally, consider solutions to avoid this failure
    Project management
    Programming languages
    • JavaScript and maybe another interpreted language (Python, Ruby, etc.). Interpreted languages are useful for quick one-off automation scripts, and the 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...).
    • These new perspectives, these ideas, and patterns — they linger, they stay with you, even if you end up in another language. And that is powerful enough to keep on learning new languages because one of the best things that can happen to you when you’re trying to solve a problem is a change of perspective.
    Python
    JavaScript
    Functional programming
    • 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 the 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.
    • 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
    • Don’t even start considering solutions until you understand the problem. Your goal should be to “solve” the problem mostly within the problem domain, not the solution domain.
    • eNumerate multiple candidate solutions. Don’t just start prodding at your favorite!
    Reading
    • Papers we love papers from the computer science community to read and discuss. Can be a good source of inspiration for solving your design problems.
    Refactoring
    • 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.
    Releasing & deploying
    • Flipping out, Flickr. One of the first articles about feature flags.
    • Deliver new functionality to users rapidly but safely
    • Release Toggles allow incomplete and un-tested code paths 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.
    • 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).
    • 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 risks) 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 grey 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)
    Security
    • Web Developer Security Checklist
    • There is a big overlap between secure code and good software design
    • Every domain value should instead be represented by a domain primitive.
    • External input needs to be validated before it is used in the system, in the following order: origin, size, lexical content, syntax, and semantics.
    • Entities should be consistent at creation, have limited operation, and shouldn't be sharing mutable objects.
    • Three Rs to do every few hours: rotate secrets automatically, repave servers and applications (redeploy on clean footprint), and repair vulnerable.
    • Don’t use exceptions for the control flow.
    Shell (command line)
    System administration
    System architecture
    • High Scalability: a great blog about system architecture, its weekly review article is packed with numerous insights and interesting technology reviews. Check out the all-time favorites.
    • "We’re gonna break it up and somehow find the engineering discipline we never had in the first place."
    • Focus effort on systems-level failure, instead of the individual component failure.
    • Invest in sophisticated observability tools, aiming to increase the number of questions we can ask without deploying custom code
    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)
    • 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.
    • A good summary of processes to implement.
    • Code in production is the only code that matters
    • Engineers are the subject matter experts for the code they write and should be responsible for operating it in production.
    • Buy Almost Always Beats Build
    • Make Deploys Easy
    • Trust the People Closest to the Knives
    • QA Gates Make Quality Worse
    • Boring Technology is Great.
    • Non-Production Environments Have Diminishing Returns
    • Things Will Always Break
    • A good availability metric should be meaningful, proportional, and actionable. By "meaningful" we mean that it should capture what users experience. By "proportional" we mean that a change in the metric should be proportional to the change in user-perceived availability. By "actionable" we mean that the metric should give system owners insight into why availability for a period was low. This paper shows that none of the commonly used metrics satisfies these requirements…
    Technical debt
    • technical debt, Martin Fowler.
    • You don't need to stop shipping features to fix technical debt
    • Communicate the business value
    Testing
    • Even if you don’t, someone will test your software
    • The majority of testing should be performed by development teams
    • Manual testing should not be the majority of your testing because manual testing is O(n)
    • Tests are the critical component that ensures you can always ship your master branch
    • Tests lock-in behavior
    • Tests give you the confidence to change someone else’s code
    • Be clear about the different types of tests that you want to write. Agree on the naming in your team and find consensus on the scope of each type of test.
    • Every single test in your test suite is additional baggage and doesn't come for free.
    • Test code is as important as production code.
    Tools
    • DevChecklist: a collaborative space for sharing checklists that help ensure software quality
    Version control (Git)
    Work ethics, productivity & work/life balance
    • 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
    • Context intentionality is the key difference between home and every other place on planet earth
    • Rules are about exceptions
    • 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.
    Web development
    • grab/front-end guide: a study guide and introduction to the modern front-end stack.
    • A Directory of design and front-end resources
    Writing (communication)
    • 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 realize your system design was flawed or it doesn't address any real user needs."
    • 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.
    Writing for performance
    • You can't tell where a program is going to spend its time.
    • Measure
    • Fancy algorithms are slow when n is small, and n is usually small.
    • Fancy algorithms are buggier than simple ones
    • Data dominates.
    Resources & inspiration for presentations
    • Dilbert
    • Calvin & Hobbes
    Concepts

    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:

    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.

    I've found these books incredibly inspiring:

    There are some free books available, including:

    List of axioms:


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

    Example implementations:

    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.

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

    Articles :

    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)

    Tools

    Check out my list of management resources.

    Articles

    Check out my list of management resources.

    The best way to learn is to learn by doing.

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

    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.

    Learn how to learn!

    Richard Feynman's Learning Strategy:

    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

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

    I would recommend learning:

    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)

    For Python feel free to check out my professional Python education repository.

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

    “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 systematics, an essay on how systems work, and especially how they fail..., 1975 (this quote is sometimes referred to 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

    List of resources:

    Books:

    Articles:

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

    Resources:

    ➡️ See also my engineering-management list

    • 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 realize your system design was flawed or it doesn't address any real user needs."
    • 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.
    Writing for performance
    • You can't tell where a program is going to spend its time.
    • Measure
    • Fancy algorithms are slow when n is small, and n is usually small.
    • Fancy algorithms are buggier than simple ones
    • Data dominates.
    Resources & inspiration for presentations
    • Dilbert
    • Calvin & Hobbes
    Concepts
    >

    Tags:
    4.94 / 169 rates

    Post a Comment

    Previous Post Next Post