In computer programming, you can make something faster at the cost of needing more (random access) memory or decrease its memory needs at the cost of being slower. A lot of computer evolution, both in hardware and software, has been finding ways to improve the exchange rate or just straight increase the number of resources available to fiddle with.

freeCodeCamp dev quiz - Software Design

- The five phases of the Design Thinking Process are Empathize, Define, Ideate, Prototype, and Test.
- what is grep?
- The Design Thinking Process is a way to come up with creative, user centric solutions to complex problems.
- [The Design Thinking Process Explained](https://www.freecodecamp.org/news/the-design-thinking-process-explained)
- When Pair Programming, one developer is the "driver" with their hands on the keyboard. The other is the "navigator" helping talk through the problem and decide what to do. They periodically switch roles. This is an efficient and commonly used Agile Software Development methodology.

Software needs the ability to code events and objects in such a way
that rough-and-ready versions of statistical principles can be applied
to them.

A building or object should let you use it as you want: a good building,
for example, will serve as a backdrop for whatever life people want to
lead in it, instead of making them live as if they were executing a
program written by the architect.

Hackers need to understand the theory of computation about as much as
painters need to understand paint chemistry.

You should figure out programs as you're writing them, just as writers
and painters and architects do. Realizing this has real implications for
software design. It means that a programming language should, above all,
be malleable. A programming language is for thinking of programs, not
for expressing programs you've already thought of. It should be a
pencil, not a pen.

There are quite a few occasions where an already-present tool should be rebuilt:  
- It's often hard to find _precisely_ what you want, and refactoring can be complicated.
- Some software developers reinvent the wheel or [reverse-engineer something](https://trendless.tech/hacking), just for fun.
- Reinventing the wheel is very educational, even if its results aren't always useful.
- An existing tool might become obsolete, jammed behind a paywall, merged into some bloated software suite, or the software's owner [became tyrannical](https://gainedin.site/bad-systems/) over [their IP](https://notageni.us/ip).
- For any reason whatsoever, a developer may start distrusting software and will make a lobotomized or [open-source](https://trendless.tech/floss/) version of it.
The largest mental wall for most people, though, is knowing a tool even _exists_. If we know another human already did something, we now know it's completely possible, and it's much easier to find motivation to accomplish what we're certain can happen.

## new sites - dev influencers

[Alex Alejandre](https://alexalejandre.com/)

[larry wall](http://www.wall.org/~larry/)
[larry wall](https://web.archive.org/web/20210102182957/http://www.wall.org/~larry/)
the creator of the perl programming language's personal site

[stallman](https://stallman.org/)
richard stallman. nuff said.

[Ask HN: Share your favorite software blog posts of 2023 | Hacker News](https://news.ycombinator.com/item?id=38765176)

[GitHub - sanmak/awesome-blogs: List of awesome blogs run, managed by a human or two and not an organisation, company or institution.](https://github.com/sanmak/awesome-blogs)

[GitHub - m8/refined.blog: curated list of personal blogs](https://github.com/m8/refined.blog)
[Refined Blog](https://m8.github.io/refined.blog/)

[lolwut](https://lolwut.neocities.org/)
[lolwut](https://web.archive.org/web/20210102182957/https://lolwut.neocities.org/)
personal site of a /g/ anon. cool stuff in here

[rmccurdy.com/](https://rmccurdy.com/)

[Randall Bytwerk](https://www.bytwerk.com/)

[za3k.com](https://za3k.com/)

[Hunter Harris's Resume](https://hbh7.com/resume/)

[jwills.co.uk - Coding, retro-gaming, and other projects](https://jwills.co.uk/)

[Greg Tatum](https://gregtatum.com/)

[GitHub - STRML/strml.net: STRML: Projects & Work](https://github.com/STRML/strml.net)
[STRML: Projects and Work](https://www.strml.net/)

[GitHub - jkup/awesome-personal-blogs: A delightful list of personal tech blogs](https://github.com/jkup/awesome-personal-blogs)

[Dev Mastery Newsletter Opt-In](https://www.devmastery.com/)

[Pointer | A Reading Club For Software Developers](https://www.pointer.io/)

[Paper Trail](https://www.the-paper-trail.org)

[Shamus Young Dot Com](https://www.shamusyoung.com/)

### twitter accounts

##### ▪️ Best Personal Twitter Accounts

[@blackroomsec](https://twitter.com/blackroomsec)
a white-hat hacker/pentester. Intergalactic Minesweeper Champion 1990.

[@MarcoCiappelli](https://twitter.com/MarcoCiappelli)
Co-Founder @ITSPmagazine, at the intersection of IT security and society.

[@binitamshah](https://twitter.com/binitamshah)
Linux Evangelist. Malwares. Kernel Dev. Security Enthusiast.

[@joe_carson](https://twitter.com/joe_carson)
an InfoSec Professional and Tech Geek.

[@mikko](https://twitter.com/mikko)
CRO at F-Secure, Reverse Engineer, TED Speaker, Supervillain.

[@esrtweet](https://twitter.com/esrtweet)
often referred to as ESR, is an American software developer, and open-source software advocate.

[@gynvael](https://twitter.com/gynvael)
security researcher/programmer, @DragonSectorCTF founder/player, technical streamer.

[@x0rz](https://twitter.com/x0rz)
Security Researcher & Cyber Observer.

[@TinkerSec](https://twitter.com/TinkerSec)
tinkerer, cypherpunk, hacker.

[@alisaesage](https://twitter.com/alisaesage)
independent hacker and researcher.

[@SwiftOnSecurity](https://twitter.com/SwiftOnSecurity)
systems security, industrial safety, sysadmin, author of decentsecurity.com.

[@dakami](https://twitter.com/dakami)
is one of just seven people with the authority to restore the DNS root keys.

[@samykamkar](https://twitter.com/samykamkar)
is a famous "grey hat" hacker, security researcher, creator of the MySpace "Samy" worm.

[@jack_daniel](https://twitter.com/jack_daniel)
@SecurityBSides co-founder.

[@thegrugq](https://twitter.com/thegrugq)
Security Researcher.

##### ▪️ Best Commercial Twitter Accounts

[@attcyber](https://twitter.com/attcyber)
AT&T Cybersecurity's Edge-to-Edge technologies provide threat intelligence, and more.

[@hedgehogsec](https://twitter.com/hedgehogsec)
Hedgehog Cyber. Gibraltar and Manchester's top boutique information security firm.

## new sites - engineering blogs

[GitHub - flesch/random-engineering-blog: Bored? Read a random engineering blog.](https://github.com/flesch/random-engineering-blog)

[GitHub - kilimchoi/engineering-blogs: A curated list of engineering blogs](https://github.com/kilimchoi/engineering-blogs)

[GitHub - MartinsOnuoha/company-engineering-blogs: A collection of companies' engineering blogs, to help you improve your software engineering skill and learn how their software work. ](https://github.com/MartinsOnuoha/company-engineering-blogs)

## skills

NOTE: indicate stuff like exercism and hacktoberfest for the purposes of sharpening the sword.

## veteran advice

When making software on a website, make it as easy and quick as possible for the new leads to poke around with it
if people get to "test drive" it, they can feel what the product is capable of

Programming languages are what programmers think in.

### Code

Code is a liability, not an asset. Aim to have as little of it as possible.

Build programs out of pure functions. This saves you from spending your brain power on tracking side effects, mutated state and actions at a distance.

Use a programming language with a rich type system that lets you describe the parts of your code and checks your program at compile time.

The expressivity of a programming language matters hugely. It’s not just a convenience to save keypresses, it directly influences the way in which you write code.

Choose a programming language that has a good module system, and use it. Be explicit about the public interface of a module, and ensure its interals don't leak out to client code.

Code is a living construct that is never “done”. You need to tend it like a garden, always improving and tidying it, or it withers and dies.

Have the same high standards for all the code you write, from little scripts to the inner loop of your critical system.

Write code that is exception safe and resource safe, always, even in contexts where you think it won’t matter. The code you wrote in a little ad-hoc script will inevitably find its way into more critical or long-running code.

Use the same language for the little tools and scripts in your system too. There are few good reasons to drop down into bash or Python scripts, and some considerable disadvantages.

In code, even the smallest details matter. This includes whitespace and layout!


### Design

Modelling - the act of creating models of the world - is a crucial skill, and one that’s been undervalued in recent years.

Model your domain using types.

Model your domain first, using data types and function signatures, pick implementation technologies and physical architecture later.

Implement functionality in vertical slices that span your whole system, and iterate to grow the system.

Resist the temptation to use your main domain types to describe interfaces or messages exchanged by your system. Use separate types for these, even if it entails some duplication, as these types will evolve differently over time.

Prefer immutability always. This applies to data storage as well as in-memory data structures.

When building programs that perform actions, model the actions as data, then write an interpreter that performs them. This makes your code much easier to test, monitor, debug, and refactor.

Dependency management is crucial, so do it from day one. The payoff for this mostly comes when your system is bigger, but it’s not expensive to do from the beginning and it saves massive problems later.

Avoid circular dependencies, always.


### Quality

I don’t care if you write the tests first, last, or in the middle, but all code must have good tests.

Tests should be performed at different levels of the system. Don’t get hung up on what these different levels of tests are called.

Absolutely all tests should be automated.

Test code should be written and maintained as carefully as production code.

Developers should write the tests.

Run tests on the production system too, to check it’s doing the right thing.


### Designing systems

A better system is often a smaller, simpler system.

To design healthy systems, divide and conquer. Split the problem into smaller parts.

Divide and conquer works recursively: divide the system into a hierarchy of simpler sub-systems and components.
	
_Corollary: When designing a system, there are more choices than a monolith vs. a thousand “microservices”._

The interface between parts is crucial. Aim for interfaces that are as small and simple as possible.

Data dependencies are insidious. Take particular care to manage the coupling introduced by such dependencies.

Plan to evolve data definitions over time, as they will inevitably change.

Asynchronous interfaces can be useful to remove temporal coupling between parts.

Every inter-process boundary incurs a great cost, losing type safety, and making it much harder to reason about failures. Only introduce such boundaries where absolutely necessary and where the benefits outweigh the cost.

Being able to tell what your system is doing is crucial, so make sure it’s observable.

Telling what your system has done in the past is even more crucial, so make sure it’s auditable.

A modern programming language is the most expressive tool we have for describing all aspects of a system.

This means: write configuration as code, unless it absolutely, definitely has to change at runtime.

Also, write the specification of the system as executable code.

And, use code to describe the infrastructure of your system, in the same language as the rest of the code. Write code that interprets the description of your system to provision actual physical infrastructure.

At the risk of repeating myself: everything is code.

_Corollary: if you’re writing JSON or YAML by hand, you’re doing it wrong. These are formats for the machines, not for humans to produce and consume. (Don’t despair though: most people do this, I do too, so you’re not alone! Let's just try to aim for something better)._

The physical manifestation of your system (e.g. choices of storage, messaging, RPC technology, packaging and scheduling etc) should usually be an implementation detail, not the main aspect of the system that the rest is built around.

It should be easy to change the underlying technologies (e.g. for data storage, messaging, execution environment) used by a component in your system, this should not affect large parts of your code base.

You should have at least two physical manifestations of your system: a fully integrated in-memory one for testing, and the real physical deployment. They should be functionally equivalent.

You should be able to run a local version of your system on a developer’s computer with a single command. With the capacity of modern computers, there is absolutely no rational reason why this isn’t feasible, even for big, complex systems.

There is a running theme here: separate the description of _what_ a system does from _how_ it does it. This is probably the single most important consideration when creating a system.


### Building systems

For a new system, get a walking skeleton deployed to production as soon as possible.

Your master branch should always be deployable to production.

Use feature branches if you like. Modern version control tools make merging easy enough that it’s not a problem to let these be long-lived in some cases.

Ideally, deploy automatically to production on every update to master. If that’s not feasible, it should be a one-click action to perform the deployment.

Maintain a separate environment for situations when you find it useful to test code separately from production. Avoid more than one such extra environment, as this introduces overheads and cost.

Prefer feature flags and similar mechanisms to control what's enabled in production over separate test/staging environments and manual promotion of releases.

Get in the habit of deploying from master to production from the very beginning of a project. Doing this shapes both your system and how you work with it for the better.

In fact, follow all these practices from the very beginning of a new system. Retrofitting them later is much, much harder.


### Technology

Beware of hyped or fashionable technologies. The fundamentals of computer science and engineering don’t change much over time.

Keep up with latest developments in technology to see how they can help you, but be realistic about what they can do.

Choose your data storage backend according to the shape of data, types of queries needed, patterns of writes vs. reads, performance requirements, and more. Every use case is different.

That said, PostgreSQL should be your default and you should only pick something else if you have a good reason.

## add dir

[Add dir="auto" to your inputs and textareas | Hacker News](https://news.ycombinator.com/item?id=37233902)
[PSA: Add dir="auto" to your inputs and textareas. | Mo - Pure...](https://mough.xyz/312/psa-add-dir-auto-to-your-inputs-and-textareas)

## a_philosophy_of_software_design

### Highlights from John Ousterhout : A Philosophy of Software Design ##

My favorite bytes from the wonderful book [A Philosophy of Software Design](https://www.goodreads.com/book/show/39996759-a-philosophy-of-software-design) By [John Ousterhout](https://web.stanford.edu/~ouster/cgi-bin/home.php)

* What is the simplest interface that will cover all my current needs?
* If you have to introduce lots of additional arguments in order to reduce the number of methods, then you may not really be simplifying things.
* See if you can replace several special-purpose methods with a single general-purpose method.
* Making your modules somewhat general-purpose is one of the best ways to reduce overall system complexity.
* Red Flag: Pass-Through Method
* Having methods with the same signature is not always bad. The important thing is that each new method should contribute significant functionality. Pass-through methods are bad because they contribute no new functionality.
* Could you merge the new functionality with an existing decorator, rather than creating a new decorator? This would result in a single deeper decorator class rather than multiple shallow ones.
* It is more important for a module to have a simple interface than a simple implementation.
* Before exporting a configuration parameter, ask yourself: “will users (or higher-level modules) be able to determine a better value than we can determine here?”
* Configuration parameters result in an incomplete solution, which adds to system complexity.
* When you encounter a class that includes both general-purpose and special-purpose features for the same abstraction, see if the class can be separated into two classes, one containing the general-purpose features, and the other layered on top of it to provide the special-purpose features.
* The key design decision was the one that separated the general-purpose part of the undo mechanism from the special-purpose parts and put the general-purpose part in a class by itself. Once that was done, the rest of the design fell out naturally.
* You shouldn’t break up a method unless it makes the overall system simpler.
* When designing methods, the most important goal is to provide clean and simple abstractions. Each method should do one thing and do it completely.
* Red Flag: Conjoined Methods It should be possible to understand each method independently. If you can’t understand the implementation of one method without also understanding the implementation of another, that’s a red flag.
* Code that hasn’t been executed doesn’t work.
* Thus, special cases should be eliminated wherever possible. The best way to do this is by designing the normal case in a way that automatically handles the special cases without any extra code.
* The design-it-twice approach not only improves your designs, but it also improves your design skills. The process of devising and comparing multiple approaches will teach you about the factors that make designs better or worse. Over time, this will make it easier for you to rule out bad designs and hone in on really great ones.
* Change amplification: a seemingly simple change requires code modifications in many places. Cognitive load: in order to make a change, the developer must accumulate a large amount of information. Unknown unknowns: it is unclear what code needs to be modified, or what information must be considered in order to make those modifications.
* After you have written a comment, ask yourself the following question: could someone who has never seen the code write the comment just by looking at the code next to the comment? If the answer is yes, as in the examples above, then the comment doesn’t make the code any easier to understand.
* Add a comment before each of the major blocks to provide a high-level (more abstract) description of what that block does.
* However, I consider any unsolved bug to be an intolerable personal insult, so I decided to track it down.
* Unfortunately, most developers don’t spend much time thinking about names. They tend to use the first name that comes to mind, as long as it’s reasonably close to matching the thing it names. For example, block is a pretty close match for both a physical block on disk and a logical block within a file; it’s certainly not a horrible name. Even so, it resulted in a huge expenditure of time to track down a subtle bug.
* Thus, you shouldn’t settle for names that are just “reasonably close”. Take a bit of extra time to choose great names, which are precise, unambiguous, and intuitive. The extra attention will pay for itself quickly, and over time you’ll learn to choose good names quickly.
* If you find it difficult to come up with a name for a particular variable that is precise, intuitive, and not too long, this is a red flag. It suggests that the variable may not have a clear definition or purpose.
* When this happens, consider alternative factorings. For example, perhaps you are trying to use a single variable to represent several things; if so, separating the representation into multiple variables may result in a simpler definition for each variable. The process of choosing good names can improve your design by identifying weaknesses.
* Red Flag: Hard to Pick Name If it’s hard to find a simple name for a variable or method that creates a clear image of the underlying object, that’s a hint that the underlying object may not have a clean design.
* The greater the distance between a name’s declaration and its uses, the longer the name should be.
* Whenever you modify any code, try to find a way to improve the system design at least a little bit in the process. If you’re not making the design better, you are probably making it worse.
* The best way to ensure that comments get updated is to position them close to the code they describe.
* Don’t put all the comments for an entire method at the top of the method. Spread them out, pushing each comment down to the narrowest scope that includes all of the code referred to by the comment.
* In general, the farther a comment is from the code it describes, the more abstract it should be (this reduces the likelihood that the comment will be invalidated by code).
* Comments belong in the code, not the commit log.
* If you want to include a copy of this information in the commit message as well, that’s fine, but the most important thing is to get it in the code.
* Don’t redocument one module’s design decisions in another module. For example, don’t put comments before a method call that explain what happens in the called method. If readers want to know, they should look at the interface comments for the method.
* Try to make it easy for developers to find appropriate documentation, but don’t do it by repeating the documentation. If information is already documented someplace outside your program, don’t repeat the documentation inside the program; just reference the external documentation.
* It’s important that readers can easily find all the documentation needed to understand your code, but that doesn’t mean you have to write all of that documentation.
* Higher-level comments are easier to maintain.
* On the other hand, if the system is consistent, assumptions made based on familiar-looking situations will be safe. Consistency allows developers to work more quickly with fewer mistakes.
* In Rome, do as the Romans do.
* Overall, reconsidering established conventions is rarely a good use of developer time.
* You must put yourself in the position of the reader and figure out what is likely to confuse them, and what information will clear up that confusion.
* Software should be designed for ease of reading, not ease of writing.
* The more different implementations there are of an interface, the deeper the interface becomes.
* Although the mechanisms provided by object-oriented programming can assist in implementing clean designs, they do not, by themselves, guarantee good design. For example, if classes are shallow, or have complex interfaces, or permit external access to their internal state, then they will still result in high complexity.
* One of the risks of agile development is that it can lead to tactical programming. Agile development tends to focus developers on features, not abstractions, and it encourages developers to put off design decisions in order to produce working software as soon as possible.
* Developing incrementally is generally a good idea, but the increments of development should be abstractions, not features.
* Some agile practitioners argue that you shouldn’t implement general-purpose mechanisms right away; implement a minimal special-purpose mechanism to start with, and refactor into something more generic later, once you know that it’s needed. Although these arguments make sense to a degree, they argue against an investment approach, and they encourage a more tactical style of programming. This can result in a rapid accumulation of complexity.
* The problem with test-driven development is that it focuses attention on getting specific features working, rather than finding the best design.
* The units of development should be abstractions, not features.
* One place where it makes sense to write the tests first is when fixing bugs. Before fixing a bug, write a unit test that fails because of the bug.
* The most important idea is still simplicity: not only does simplicity improve a system’s design, but it usually makes systems faster.
* Simpler code tends to run faster than complex code. If you have defined away special cases and exceptions, then no code is needed to check for those cases and the system runs faster. Deep classes are more efficient than shallow ones, because they get more work done for each method call. Shallow classes result in more layer crossings, and each layer crossing adds overhead.
* Performance isn’t as important for special cases, so you can structure the special-case code for simplicity rather than performance.
* The key is simplicity again: find the critical paths that are most important for performance and make them as simple as possible.

## api

[Modern storage is plenty fast, but the APIs are bad | Hacker News](https://news.ycombinator.com/item?id=25220892)
[Modern storage is plenty fast. It is the APIs that are bad. | by Glauber Costa | ITNEXT](https://itnext.io/modern-storage-is-plenty-fast-it-is-the-apis-that-are-bad-6a68319fbc1a)

[API Tokens: A Tedious Survey | Hacker News](https://news.ycombinator.com/item?id=28295348)
[API Tokens: A Tedious Survey · The Fly Blog](https://fly.io/blog/api-tokens-a-tedious-survey/)

[API pagination design | Hacker News](https://news.ycombinator.com/item?id=25547716)
[API pagination design](https://solovyov.net/blog/2020/api-pagination-design/)

[Popover API | Hacker News](https://news.ycombinator.com/item?id=40317740)
[Popover API - Web APIs | MDN](https://developer.mozilla.org/en-US/docs/Web/API/Popover_API)

[Zdenek Nemec (Z, zdne)](https://blog.goodapi.co/api-maturity-fb25560151a3)
(2018) API Maturity

[Gregg Caines](http://caines.ca/blog/2013/09/13/you-probably-dont-need-to-version-your-web-api/)
(2013) You Probably Don’t Need to Version Your Web API.
:star:

[Martin Nally](https://apigee.com/about/blog/api-technology/api-design-choosing-between-names-and-identifiers-urls)
(2017) API Design: Choosing Between Names and Identifiers in URLs

[If you're just going to sit there doing nothing, at least do nothing correctly | Hacker News](https://news.ycombinator.com/item?id=39401598)
[If you're just going to sit there doing nothing, at least do nothing correctly - The Old New Thing](https://devblogs.microsoft.com/oldnewthing/20240216-00/?p=109409)

[Show HN: OpenAPI DevTools - Chrome extension that generates an API spec | Hacker News](https://news.ycombinator.com/item?id=38012032)
[AndrewWalsh/openapi-devtools: Browser extension that generates API specs for any app or website](https://github.com/AndrewWalsh/openapi-devtools)
[OpenAPI DevTools](https://chromewebstore.google.com/detail/openapi-devtools/jelghndoknklgabjgaeppjhommkkmdii)

[GitHub - WICG/floc: FLoC](https://github.com/WICG/floc#opting-out-of-computation)
[GitHub - patcg-individual-drafts/topics: The Topics API](https://github.com/patcg-individual-drafts/topics)

[Using on-demand resources for securely storing API keys](https://github.com/laevandus/OnDemandAPIKeyExample)

## api - abusing apis

[nixCraft 🐧: "Modern software development be…" - Mastodon](https://mastodon.social/@nixCraft/112176238314665179)

## api - GraphQL

[GraphQL kinda sucks | Hacker News](https://news.ycombinator.com/item?id=32366759)

[GraphQL Is a Trap? | Hacker News](https://news.ycombinator.com/item?id=31284846)
[GraphQL is a Trap?. This twitter thread blew up on twitter… | by Marc-André Giroux | Medium](https://xuorig.medium.com/graphql-is-a-trap-e83ca380aa8f)

[Why not use GraphQL? | Hacker News](https://news.ycombinator.com/item?id=25014582)
[Why not use GraphQL? - WunderGraph](https://wundergraph.com/blog/why_not_use_graphql)

[After 6 years, I'm over GraphQL | Hacker News](https://news.ycombinator.com/item?id=40521518)
[Why, after 6 years, I’m over GraphQL](https://bessey.dev/blog/2024/05/24/why-im-over-graphql/)

## api - Heroku

[Heroku Security Notification | Hacker News](https://news.ycombinator.com/item?id=31048646)
[Heroku Status](https://status.heroku.com/incidents/2413)
[Heroku Security Notification | Hacker News](https://news.ycombinator.com/item?id=31269062)
[Heroku Status](https://status.heroku.com/incidents/2413?updated)

[Remind HN: Heroku will delete all free dbs and shut down all free dynos Monday | Hacker News](https://news.ycombinator.com/item?id=33755651)

## api - REST api

[Trevor Reed](https://medium.com/@trevorhreed/you-re-api-isn-t-restful-and-that-s-good-b2662079cf0e)
(2016) Your API isn’t RESTful — And That’s Good
stop using the terms REST and RESTful to describe APIs that aren’t RESTful. It’s hurting our APIs and confusing the purpose and definition of REST.

[Gregg Caines](http://caines.ca/blog/2013/04/21/3-terrible-anti-patterns-for-error-handling-in-rest-apis/)
(2013) 3 Terrible Anti-patterns for Error-Handling in 'REST' APIs:

[Lexicalscope Ltd](http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/)
(2012) How are REST APIs versioned?

[Martin Fowler](https://martinfowler.com/articles/richardsonMaturityModel.html)
(2010) Richardson Maturity Model
steps toward the glory of REST

[Damien Frémont](https://damienfremont.com/2017/11/23/rest-api-maturity-levels-from-0-to-5/)
(2017) REST API Maturity Levels : From 0 to 5

## api - specific organization api

[Zoom now has an SDK for putting Zoom into other things - The Verge](https://www.theverge.com/2021/3/23/22347023/zoom-sdk-developers-announced-apps-audio-video-features-software)

[Stripe Treasury | Hacker News](https://news.ycombinator.com/item?id=25289626)
[Stripe Treasury | Banking-as-a-Service for Embedded Finance](https://stripe.com/treasury)

[Stripe API reference - curl](https://stripe.com/docs/api)

## automation - apple

[Workflow Update Brings Ability to Interact with Any Web API - MacStories](https://www.macstories.net/ios/workflow-update-brings-ability-to-interact-with-any-web-api)

[Workflow Tips for Beginners | Sayz Lim](https://sayzlim.net/workflow-tips-beginners)

## automation - dev tools

[A collection of 150+ "what are the best" dev questions with answers : learnprogramming](https://old.reddit.com/r/learnprogramming/comments/3r7lhp/a_collection_of_150_what_are_the_best_dev)

[Ask HN: What overlooked class of tools should a self-taught programmer look into | Hacker News](https://news.ycombinator.com/item?id=19900955)

[An ex-Googler's guide to dev tools | Hacker News](https://news.ycombinator.com/item?id=25217291)
[Dev tools: The ex-Googler guide](https://sourcegraph.com/blog/ex-googler-guide-dev-tools)

[Ask HN: Which tools have made you a much better programmer? | Hacker News](https://news.ycombinator.com/item?id=23468193)

[The Missing Semester of Your CS Education | Hacker News](https://news.ycombinator.com/item?id=34934216)
[MIT Hacker Tools: a lecture series on programmer tools | Hacker News](https://news.ycombinator.com/item?id=19078281)
[The Missing Semester of Your CS Education](https://missing.csail.mit.edu/)
The Missing Semester of Your CS Education (MIT course)

## automation

[How I track my life with Integromat, Airtable, Shortcuts and Timing (et al) Web Automators Talk](https://talk.automators.fm/t/how-i-track-my-life-with-integromat-airtable-shortcuts-and-timing-et-al/5507/31)
[Shortcut to read and format multiple IFTTT notifications containing URLs](https://talk.automators.fm/t/shortcut-to-read-and-format-multiple-ifttt-notifications-containing-urls/3825)
[Automators Talk](https://talk.automators.fm/)

[Why You Should Modularise Your Automation Code | by Colin Wren | The Startup | Medium](https://medium.com/swlh/why-you-should-modularise-your-automation-code-7703c45fdbe8)

[What work activity have you automated? : learnpython](https://old.reddit.com/r/learnpython/comments/boywle/what_work_activity_have_you_automated)

[Tim Hall](https://oracle-base.com/blog/2018/06/12/why-automation-matters-lost-time/)
(2018) Why Automation Matters : Lost Time

[Michele Lim](https://community.atlassian.com/t5/Marketplace-Apps-articles/The-7-hacks-of-highly-successful-automation/ba-p/871490)
(2018) The 7 hacks of highly successful automation

[Tracking supermarket prices with Playwright | Hacker News](https://news.ycombinator.com/item?id=41173335)
[Tracking supermarket prices with playwright](https://www.sakisv.net/2024/08/tracking-supermarket-prices-playwright/)

## backend

[futurice/backend-best-practices](https://github.com/futurice/backend-best-practices)
An evolving description of general best practices for backend development.

## be extremely specific

[Please put units in names | Hacker News](https://news.ycombinator.com/item?id=30749134)
[Please put units in names](https://ruudvanasseldonk.com/2022/03/20/please-put-units-in-names)

## billing systems

[Billing systems are a nightmare for engineers | Hacker News](https://news.ycombinator.com/item?id=31424450)
[Lago Blog - 😵 💫 Why billing systems are a nightmare for engineers](https://www.getlago.com/blog/why-billing-systems-are-a-nightmare-for-engineers)

## bucking trends

[Ask HN: What non-AI products are you working on? | Hacker News](https://news.ycombinator.com/item?id=39829695)
- THE GREAT DEVS ARE ESSENTIALLY [ARTISTS]

[The Weird Nerd comes with trade-offs | Hacker News](https://news.ycombinator.com/item?id=40624924)
[The Weird Nerd comes with trade-offs - by Ruxandra Teslo](https://www.writingruxandrabio.com/p/the-weird-nerd-comes-with-trade-offs)

## building a great codebase

[Ask HN: What is the best code base you ever worked on? | Hacker News](https://news.ycombinator.com/item?id=40818809)

## building an app

[Why I built a dictionary app | Hacker News](https://news.ycombinator.com/item?id=32300466)
[Why I built a dictionary app even with more than +300 apps available at AppStore?](https://www.wordnote.app/blog/why-i-built-dictionary-app)
[Wordnote](https://github.com/zehfernandes/wordnote)
The fast way to check a word definition

[How and why I built Japan Dev | Hacker News](https://news.ycombinator.com/item?id=32479731)
[How and why I built Japan Dev | Japan Dev](https://japan-dev.com/blog/how-and-why-i-built-japan-dev)

## building a text editor

[Over the past 21 months I've written a code editor from the ground up | Hacker News](https://news.ycombinator.com/item?id=34577246)
[Edita](https://edita.vercel.app/blog/approach/)

## coding sucks

[Software engineers hate code | Hacker News](https://news.ycombinator.com/item?id=36642796)
[Software engineers hate code.](https://www.dancowell.com/software-engineers-hate-code/)

[How much programming do you use at your job?](https://old.reddit.com/r/cybersecurity/comments/15gin25/how_much_programming_do_you_use_at_your_job/)

## compilation

[303: Compiling - explain xkcd](https://www.explainxkcd.com/wiki/index.php/303:_Compiling)

## design patterns - go

[tmrts/go-patterns: Curated list of Go design patterns, recipes and idioms](https://github.com/tmrts/go-patterns)

[Kristof Kovacs](https://kkovacs.eu/the-death-star-design-pattern)
The Death Star Design Pattern

## design patterns

[Brian Kelly](https://morethancoding.com/2013/03/12/ux-then-architecture-then-tools/)
(2013) UX, Then Architecture, Then Tools

[Joshua Kerievsky](https://www.industriallogic.com/blog/sufficient-design/)
(2010) Sufficient Design
> we need high design quality for stuff that is critical to our products and less design quality for stuff that isn't critical.

[Kamil Grzybek](https://www.kamilgrzybek.com/design/feature-folders/)
(2018) Feature Folders
on codebase design

[Martin Fowler](https://www.martinfowler.com/bliki/CQRS.html)
(2011) Command Query Responsibility Segregation (CQRS)

## Electron

[Electron apps](https://www.electronjs.org/apps)
Discover hundreds of production applications built with Electron.

## Highlights from Robert Glass: Facts and Fallacies of Software Engineering ##

My favorite bytes from the wonderful book [Facts and Fallacies of Software Engineering](https://www.goodreads.com/book/show/83792.Facts_and_Fallacies_of_Software_Engineering)
By [Robert Glass](http://www.robertlglass.com/)

* People trump tools, techniques, and process.
* The problem is a culture that puts schedule conformance, using impossible schedules, above all else—a culture that values schedule so highly that there is no time to learn about new concepts.
* Runaway projects, at least those that stem from poor estimation, do not usually occur because the programmers did a poor job of programming. Those projects became runaways because the estimation targets to which they were being managed were largely unreal to begin with.
* Most often, software estimation is done by the people who want the software product. Upper management. Marketing. Customers and users. Software estimation, in other words, is currently more about wishes than reality.
* Management was "the best I've ever worked with." Why? "Because the team was given the freedom to develop a good design," because there was no "scope creep," and because "I never felt pressure from the schedule."
* "projects where no estimates were prepared at all fared best on productivity" (versus projects where estimates were performed by technologists [next best] or their managers [worst]).
* When the programmers felt in control of their fate, they were much more productive.
* Management, upon reading this story and reflecting on this fact, would in general be horrified that a project so "obviously" a failure could be seen as a success by these technologists. My further suspicion is that most technologists, upon reading this story and reflecting on this fact, would find it all quite reasonable. If my suspicions are correct, there is essentially an unspoken controversy surrounding the issue this fact addresses. And that controversy is about what constitutes project success. If we can't agree on a definition of a successful project, then the field has some larger problems that need sorting out.
* Since no one has ever been able to solve the problems we are able to solve, we believe that no new problem is too tough for us to solve.
* Reuse-in-the-small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem. Discussion There is a tendency in the computing world to assume that any good idea that comes along must be a new idea. Case in point—reuse.
See also: [From Local to Global Coordination: Lessons from Software Reuse](https://www.cc.gatech.edu/~beki/c16.pdf)
* The primary controversy here is that too many people in the computing field think that reuse is a brand-new idea. As a result, there is enormous (and often hyped) enthusiasm for this concept, an enthusiasm that would be more realistic if people understood its history and its failure to grow over the years.
* Two "rules of three" in reuse: 
  * (a) It is three times as difficult to build reusable components as single use components.
  * (b) AA reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.
* Reusable components are harder to develop and require more verification than their single-task brethren.
* Modification of reused code is particularly error-prone. If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to rewrite it from scratch.
* Design patterns emerge from practice, not from theory.
* Missing requirements are the hardest requirements errors to correct.
* Software people have dreamed of automating software processes throughout the history of the field. One by one, those dreams have been dashed.
* Notice that the underlying theme of many of the facts in this book is that the construction of software is a complex, deeply intellectual task, one that shows little possibility of being made simple. Automation is the ultimate trivialization of this nontrivial activity, and those who claim that it has been achieved are doing serious harm to the software field in its quest for better realistic tools and techniques.
* The debugging process is the detective story of programming. You play Sherlock Holmes in pursuit of the elusive software bug. And, like Sherlock Holmes, you need to enlist your brain and any brain-supporting things you can think of.
* In this era of automated everything, it is all too easy to leave the work of software testing to tools and techniques. But doing so would be a mistake.
* Research study has shown that inspections can detect up to 90 percent of the errors in a software product before any test cases have been run. 
* Error removal is a complex task, and it requires all the armament the tester can muster.
* Computer scientists have long said that formal verification, if done sufficiently rigorously, will be enough. Fault-tolerance advocates have taken the position that self-checking software, which detects and recovers from errors, will be enough. Testing people have sometimes said that 100 percent test coverage will be enough. Name your favorite error removal poison, and someone has probably made grandiose claims for it.
* In any case, I think most would agree that our field is so busy with its foot pressed to the gas pedal that it rarely has time to think about how it could be going better, not just faster. We speak of working smarter, not harder. But who has time to get in a position of working smarter?
* See also: [IEEE. 2002. "Knowledge Management in Software Engineering. Special issue."](http://publications.aston.ac.uk/id/eprint/2841/1/Chapter.pdf) IEEE Software, May. Contains several articles on postmortem reviews and the experience factory.
* That word is rigor. It is vitally important that the participants in a review process be totally dedicated to and focused on what they are doing.
* See also: [Peer Reviews in Software: A Practical Guide](https://www.goodreads.com/book/show/846008.Peer_Reviews_in_Software)
* Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.
* Software's errors aren't due to material fatigue, but rather to errors made when the software was being built or errors made as the software is being changed.
* There's an old software saying that I'd like to make into the following corollary: Old hardware becomes obsolete; old software goes into production every night.
* Software people tend to behave as if the original development of the software product is all that matters. So do academics teaching software classes.
* See also: Boehm, Barry W. 1975. "The High Cost of Software." In Practical Strategies for Developing Large Software Systems, edited by Ellis Horowitz. Reading, MA: Addison-Wesley.
* See also: Lientz, Bennet P. E., Burton Swanson, and G.E. Tompkins. 1976. "Characteristics of Applications Software Maintenance." UCLA Graduate School of Management. 
* When software is originally developed, the customers and future users really have only a partial vision of what that product can and will do for them. It's only after the product goes into production and the users use it for awhile that they begin to realize how much more the software product could be revised to do. And, frequently, they request that those changes be made.
* Changing existing product is always difficult, no matter how "soft" the software product really is.
* The 60/60 rule: 60 percent of software's dollar is spent on maintenance, and 60 percent of that maintenance is enhancement. Enhancing old software is, therefore, a big deal.
* **Maintenance is a solution, not a problem.**
  * See also: Glass, Robert L. 1991. Software Conflict. Englewood Cliffs, NJ: Yourdon Press, where this fact is stated more elaborately (a chapter is devoted to it).
* Far too many people see software maintenance as a problem, something to be diminished and perhaps even "obliterated." In saying that, they are really expressing their ignorance.
* Instead, modifying software to do something different is comparatively simple. (Notice the key word comparatively. Making changes to software is nontrivial. It's simply easier than its tangible product alternatives.)
* In examining the tasks of software development versus software maintenance, most of the tasks are the same—except for the additional maintenance task of "understanding the existing product." This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity.
* Research data tells us that understanding the existing product is the most difficult task of software maintenance.
  * Why? Well, in a sense the answer lies in many of our previous facts: The explosion when requirements are transformed into design (Fact 26). The fact that there is no single design solution to most problems (Fact 27). The fact that design is a complex, iterative process (Fact 28). The fact that for every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity (Fact 21).
  * There is another reason why understanding the existing product, or undesign, is difficult. The original designer created what we call a design envelope, a framework within which the problem, as it was known at development time, could be solved.
* The maintenance life cycle is different in one major way. Here is the maintenance life cycle according to Fjelsted and Hamlen (1979):
  * Defining and understanding the change : 15 percent
  * Reviewing the documentation for the product : 5 percent
  * Tracing logic : 25 percent
  * Implementing the change : 20 percent
  * Testing and debugging : 30 percent
  * Updating the documentation : 5 percent
* In a survey of Air Force sites in 1983, researchers found that the "**biggest problem of software maintenance" was "high [staff] turnover,**" at 8.7 (on a scale of 10). Close behind that, in second and third places, were "understanding and the lack of documentation," at 7.5, and "determining the place to make a change,"
* Notice the small percentages in the maintenance life cycle devoted to documentation activities. The maintainer spends 5 percent of his or her time "reviewing documentation" and another 5 percent "updating documentation." If you thought about those numbers at all, you may have been surprised at how small they were.
* "Unworthiness" or its complexity is for you to decide. But one of the things that lack of respect leads to is an almost total lack of what we might call maintenance documentation.
* Ongoing maintenance drives the specs and the product even further apart. The fact of the matter is, design documentation is almost completely untrustworthy when it comes to maintaining a software product. The result is, almost all of that undesign work involves the reading of code (which is invariably up to date) and ignoring the documentation (which commonly is not).
* Here again, the underlying problem is our old enemy schedule pressure. There is too much demand for the modified product to be ready.
* Perhaps it's a stretch, but I like to tell people that, because of all of the above, maintenance is a more difficult task than software development. Few people want to hear that, so I tend to say it in something of a whisper.
* See also: Glass, Robert L. 1981. "Documenting for Software Maintenance: We're Doing It Wrong." In Software Soliloquies, Computing Trends.
* Better software engineering development leads to more maintenance, not less.
* See also: Dekleva, Sasa M. 1992. "The Influence of the Information System Development Approach on Maintenance." Management Information Systems Quarterly, Sept. This study looked at the effect of using "modern development methods" on software projects from the point of view of their subsequent maintenance.
* These systems took longer to maintain than the others because more modifications were being made to them. And more modifications were being made because it was easier to enhance these better-built systems.
* We neither agree on a workable definition nor agree on whose responsibility quality in the software product is. 
* Modifiability, one of those attributes, is a matter of knowing how to build software in such a way that it can be easily modified.
* Reliability is about building software in ways that minimize the chance of it containing errors and then following that up with an error removal process that uses as many of the multifaceted error removal options as makes sense.
* Quality is one of the most deeply technical issues in the software field.
* Management's job, far from taking responsibility for achieving quality, is to facilitate and enable technical people and then get out of their way.
* It is nearly impossible to put a number on understandability or modifiability or testability or most of the other quality -ilities.
* See also: Glass, Robert L. 1992. Building Quality Software. Englewood Cliffs, NJ: Prentice-Hall. In Section 3.9.1, State of the Theory, this book is an analysis of the DoD report discussed earlier.
* Quality in the software field is about a collection of seven attributes that a quality software product should have: portability, reliability, efficiency, usability (human engineering), testability, understandability, and modifiability.
  1. Portability is about creating a software product that is easily moved to another platform. 
  2. Reliability is about a software product that does what it's supposed to do, dependably. 
  3. Efficiency is about a software product that economizes on both running time and space consumption. 
  4. Human engineering (also known as usability) is about a software product that is easy and comfortable to use. 
  5. Testability is about a software product that is easy to test. 
  6. Understandability is about a software product that is easy for a maintainer to comprehend. 
  7. Modifiability is about a software product that is easy for a maintainer to change.
* Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets, or reliability.
* User satisfaction = Meets requirements + delivered when needed + appropriate cost + quality product.
* See also: Gramms, Timm. 1987. Paper presented on "biased errors" and "thinking traps." Notices of the German Computing Society Technical Interest Group on Fault-Tolerant Computing Systems, Bremerhaven, West Germany,
* Errors tend to cluster.
* "Half the errors are found in 15% of the modules" (Davis 1995, quoting Endres 1975). 80% of all errors are found in just 2% (sic) of the modules" (Davis 1995, quoting Weinberg 1992). Given the quote that follows, it makes you wonder if 2 percent was a misprint.)
* There is no single best approach to software error removal.
* The advocates of silver bullets will continue to make exaggerated claims for whatever technique they are selling,
* See also: Glass, Robert L. 1992. Building Quality Software. Englewood Cliffs, NJ: Prentice-Hall.
* Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
* It would be nice to remove all those other errors too (for example, documentation errors, redundant code errors, unreachable path errors, errors in numerically insignificant portions of an algorithm, and so on.), but it's not always necessary.
* "Almost 90% of the downtime comes from, at most, 10% of the defects"
* Efficiency stems more from good design than from good coding.
* Interface and internal inefficiencies pale to insignificance compared to I/O inefficiencies. Still, it is possible, through poorly designed looping strategies, for a coder to make a program's logic wheels spin an inordinately long time.
* *To some eager programmers, coding is the most important task of software construction, and the sooner we get to it, the better. Design, to people in that camp, is simply something that puts off the ultimate problem solution activity.* As long as these people continue to address relatively simple problems, (a) they will probably never be convinced otherwise, and (b) there may be nothing terribly wrong with what they are doing. But it doesn't take much problem complexity before that minimal-design, quick-to-code approach begins to fall apart. (Recall Fact 21, about how quickly problem complexity drives up solution complexity?)
* Somehow it seems like anything that makes a program more time-efficient will also make it more size-efficient. But that is not true.
* Many software researchers advocate rather than investigate. As a result, (a) some advocated concepts are worth far less than their advocates believe, and (b) there is a shortage of evaluative research to help determine what the value of such concepts really is.
* It wasn't until the notion of the GQM approach (originally proposed by Vic Basili)—establish Goals to be satisfied by the metrics, determine what Questions should be asked to meet those goals, and only then collect the Metrics needed to answer just those questions—that there began to be some rationality in metrics approaches.
* No matter how many people believed that management was responsible for product quality, there was too much technology to the subject of software quality to leave it up to management.
* So what's the fallacy here? That quality is a management job. Management, of course, does have a vitally important role in achieving quality. They can establish a culture in which the task of achieving quality is given high priority. They can remove barriers that prevent technologists from instituting quality. They can hire quality people, by far the best way of achieving product quality. And they can get out of the way of those quality people, once the barriers are down and the culture is established, and let them do what they have wanted to do all along—build something they can be proud of.
* What's the alternative to an ego-invested programmer? A team-player programmer.
* Programmers really do need to be open to critique; the fact that we cannot write error-free programs, hammered home so many times in this book, means that programmers will always have to face up to their technical foibles and frailties.
* A system that works will have to acknowledge fundamental human traits and work within the bounds they create. And ego is one of those traits.
* See also: Weinberg, Gerald. 1971. The Psychology of Computer Programming.
* There are sure a lot of people in the software world who would like to believe that one size fits all. Those selling methodologies. Those defining process approaches. Those pushing tools and techniques. Those hoping to build component-based software. Those setting standards. Those doing research toward the next software engineering holy grail. Those academics who put the prefix meta- in front of whatever they're working on. All of them are seeking that "universal software elixir." Many of them even believe they have found it. All too many of them want to sell it to you!
* Because software tackles such a diverse assortment of problems, it is becoming more and more obvious that there are few, if any, universal solution approaches. What works for business application programs will never be enough for critical, real-time software projects. What works for systems programming is often irrelevant to the needs of scientific applications. What works for small projects, and that includes today's Agile Development approaches, won't work well for those huge projects that consume hundreds of programmers. What works for straightforward projects will fail miserably if applied to critical projects.
* We are just beginning, in our field, to appreciate how diverse the problems we need to solve really are.
* Criticality matters. If lives or vast sums of money are involved in a project, you will treat it far differently—especially its reliability needs—than if they are not.
* Most practitioners are well aware that "my project is different." All too many theorists, however, disdain such a comment and see that practitioner as simply unwilling to try new (and often "universal") things (but see Glass 2002a).
* "The most interesting paradigm shift now taking place" in the field is "the shift away from the notion that all software is essentially the same."
* See also: McBreen, Pete. 2002. Software Craftsmanship. Boston: Addison-Wesley. Contains a section explicitly titled One Size Does Not Fit All.
* See also: Cockburn, Alistair. 2002. Agile Software Development. Boston: Addison-Wesley. Glass, Robert L. 2002a. "Listen to Programmers Who Say 'But Our Project is Different.'" The Practical Programmer. Communications of the ACM.
* See also: The Loyal Opposition. IEEE Software. Glass, Robert L., and Östen Oskarsson. 1996. An ISO Approach to Building Quality Software. Upper Saddle River, NJ: Prentice-Hall. Highsmith, Jim. 2002.
* See also: Plauger, P.J. 1994. Programming on Purpose. Englewood Cliffs, NJ: Prentice-Hall.
* See also: Vessey, Iris, and Robert L. Glass. 1998. "Strong vs. Weak Approaches to Systems Development." Communications of the ACM, Apr.
* See also: Yourdon, Ed. 1995. "Pastists and Futurists: Taking Stock at Mid-Decade." Guerrilla Programmer, Jan.
* No one is talking about inventing more methodologies, but everyone seems to be doing it.
* Almost no software practitioners are using these methodologies straight out of the box. On the contrary, most people who use a methodology adapt it to fit the situation at hand.
* See also: Wiegers, Karl. 1998. "Read My Lips: No New Models!" IEEE Software,
* Because one program's LOC may be very different from another program's LOC: Is one line of COBOL code the same degree of complexity as one line of C++ code? Is one line of a deeply mathematical scientific application comparable to one line of a business system? Is one line of a junior programmer's code equivalent to one line from your best programmer? (See Fact 2 about those individual differences— upto 28 to 1—for an answer to that question.) Is one LOC in a heavily commented program comparable to a LOC in one with no comments? What, in fact, constitutes a LOC?
* Random test input is a good way to optimize testing.
* Via statistics-driven testing, software people can say things like "this product runs successfully 97.6 percent of the time." That's a pretty potent kind of statement to make to users. It's certainly more meaningful to those users than "this product has met 99.2 percent of its requirements" (that sounds impressive, but we already know that 100 percent requirements-driven testing is far from sufficient) or "this product has had 94.3 percent of its structure tested" (the typical user has no idea what "structure" is).
* The depth or shallowness of an error is unrelated to the number of people searching for it;
* Research on inspections suggests that the increase in the number of bugs found diminishes rapidly as the number of inspectors rises;
* The research on software inspections shows that there is a maximum number of useful inspection participants, beyond which the success of an inspection falls off rapidly (see, for example, Fact 37). And that number is quite finite—somewhere in the range of two to four.
* To build a replacement requires a source of the requirements that match the current version of the product, and those requirements probably don't exist anywhere. They're not in the documentation because it wasn't kept up to date. They're not to be found from the original customers or users or developers because those folks are long gone (for the average software product that has been around for a substantial period of time).
* The problem is this: In learning any other language, the first thing we do is learn to read it. You get a copy of Dick and Jane or War and Peace or something somewhere in between, and you read. You don't expect to write your own version of Dick and Jane or War and Peace until you've read lots of other examples of what skilled writers have written. (Believe me, writing Dick and Jane does require skill! You have to write using a vocabulary that's age- and skill-appropriate for your readers.)
* The problem is, we in the software world don't always agree on what good code or bad code is. Furthermore, most programs don't consist of just good or bad code—they contain a mixture of both.
* In spite of the fact that most programmers think that they're the best in the world at their craft, I think we have to admit that the War and Peace of software has not yet been written!
* The only time we in software tend to read code is during maintenance. Maintenance is a much disdained activity. One of the reasons for that is that code reading is a very difficult activity. It is much more fun to write new code of your own creation than to read old code of someone else's creation.
* Programmers at Work. Redmond, WA: Microsoft Press Contains this quote from a then younger Bill Gates: "[T]he best way to prepare [to be a programmer] is to write programs and to study great programs that other people have written.
* The complexity of the software process and product drives a lot of what we know and do in the field. Complexity is inevitable; we shouldn't fight it, so much as learn how to work with it. Fifteen of these facts are concerned with complexity, and a number of others are driven by it.
* Reality is the murder of a beautiful theory by a gang of ugly facts.
* And I would suggest that practitioners considering some tool, technique, method, or methodology that is at odds with one or more of these facts should beware of serious pitfalls in what they are about to embark on.

## falsehoods

[GitHub - kdeldycke/awesome-falsehood: Falsehoods Programmers Believe in](https://github.com/kdeldycke/awesome-falsehood)

[Graham Lee](http://www.sicpers.info/2017/12/falsehoods-programmers-believe-about-programming/)
(2017) Falsehoods programmers believe about programming

## figuring it out

[Developers spend most of their time figuring the system out | Hacker News](https://news.ycombinator.com/item?id=30858311)
[Developers spend most of their time figuring the system out](https://lepiter.io/feenk/developers-spend-most-of-their-time-figuri-9q25taswlbzjc5rsufndeu0py/)

## for loops

[Are nested for-loops always O(n^2)? : computerscience](https://old.reddit.com/r/computerscience/comments/vnjpvk/are_nested_forloops_always_on2)

[Push ifs up and fors down | Hacker News](https://news.ycombinator.com/item?id=38282950)
[Push Ifs Up And Fors Down](https://matklad.github.io/2023/11/15/push-ifs-up-and-fors-down.html)

## frameworks and libraries

[Why I Hate Frameworks (2005) | Hacker News](https://news.ycombinator.com/item?id=36637655)
[Why I Hate Frameworks (2005) | Hacker News](https://news.ycombinator.com/item?id=28920095)
[Factory factory factory](https://factoryfactoryfactory.net/)

["Shared libraries are not a good thing in general" | Hacker News](https://news.ycombinator.com/item?id=27009044)
[Re: Very slow clang kernel config .. - Linus Torvalds](https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/)

[Unix Sheikh](https://www.unixsheikh.com/articles/using-a-framework-can-make-you-stupid.html)
(2021) Using a framework can make you stupid!

## free dev resources

[Do Developers Still Want Swag? : programming](https://old.reddit.com/r/programming/comments/16clazd/do_developers_still_want_swag/)

## garbage collection

[Chris Lattner on garbage collection vs. Automatic Reference Counting (2017) | Hacker News](https://news.ycombinator.com/item?id=31139610)
[Episode 205: Chris Lattner Interview Transcript - Accidental Tech Podcast](https://atp.fm/205-chris-lattner-interview-transcript#gc)

## history

[Ask HN: How was life for a regular dev during the dot com burst? | Hacker News](https://news.ycombinator.com/item?id=21318704)

## law of the instrument

[The Alternative Implementation Problem | Hacker News](https://news.ycombinator.com/item?id=40337036)
[The Alternative Implementation Problem | Pointers Gone Wild](https://pointersgonewild.com/2024/04/20/the-alternative-implementation-problem/)

## local vs global descriptor

[GitHub - shamangary/awesome-local-global-descriptor: My personal note about local and global descriptor](https://github.com/shamangary/awesome-local-global-descriptor)

## make small modules

[Fagner Brack](https://medium.com/@fagnerbrack/why-small-modules-matter-4e4d629321b8)
(2016) Why Small Modules Matter
Big projects are what, if not the composition of small pieces

## multiple implementation inheritance

[Should I avoid multiple implementation inheritance?](https://stackoverflow.com/questions/53048255/should-i-avoid-multiple-implementation-inheritance)

## naming

[GitHub - gruhn/awesome-naming: A curated list for when naming things is done right.](https://github.com/gruhn/awesome-naming)

[Kuba Niechcial](https://niechcial.me/2018-01-03/remember-the-names-its-your-job)
(2018) Remember the names - it's your job

[J. B. Rainsberger](http://blog.thecodewhisperer.com/permalink/putting-an-age-old-battle-to-rest)
(2013) Putting An Age-Old Battle To Rest
Improving Names

[GitHub - ingvoo/ui-names: A collection of good (and bad) ui names.](https://github.com/ingvoo/ui-names)

## object oriented vs functional

[Railway Oriented Programming | Hacker News](https://news.ycombinator.com/item?id=37171943)
[Railway Oriented Programming | F# for fun and profit](https://fsharpforfunandprofit.com/rop/)

[Why OO Sucks by Joe Armstrong (2000) | Hacker News](https://news.ycombinator.com/item?id=19715191)
[Why OO Sucks](https://www.cs.otago.ac.nz/staffpriv/ok/Joe-Hates-OO.htm)

[Case against OOP is understated, not overstated (2020) | Hacker News](https://news.ycombinator.com/item?id=30293622)
[Case against OOP is understated, not overstated](https://boxbase.org/entries/2020/aug/3/case-against-oop/)

[Conversations with a six-year-old on functional programming | blog :: Brent - [String]](https://byorgey.wordpress.com/2018/05/06/conversations-with-a-six-year-old-on-functional-programming)

[Beyond Functional Programming: The Verse Programming Language [pdf] | Hacker News](https://news.ycombinator.com/item?id=33946933)
[A taste of Haskell - haskell-exchange-22.pdf](https://simon.peytonjones.org/assets/pdfs/haskell-exchange-22.pdf)

[What's so great about functional programming anyway? | Hacker News](https://news.ycombinator.com/item?id=33620439)
[What's so great about functional programming anyway?](https://jrsinclair.com/articles/2022/whats-so-great-about-functional-programming-anyway/)

[Seriously. Just woke up one morning and it made so much sense. : ProgrammerHumor](https://old.reddit.com/r/ProgrammerHumor/comments/13q5e67/seriously_just_woke_up_one_morning_and_it_made_so)

[Yegor Bugayenko](http://www.yegor256.com/2014/09/10/anti-patterns-in-oop.html)
(2014) Anti-Patterns in OOP

[John D. Cook](https://www.johndcook.com/blog/2017/06/09/one-practical-advantage-of-functional-programming/)
(2017) One practical application of functional programming

[Composition over inheritance](https://en.wikipedia.org/wiki/Composition_over_inheritance)
Choose Composition over inheritance

## over-optimization

[Don't DRY Your Code Prematurely | Hacker News](https://news.ycombinator.com/item?id=40525064)
[Google Testing Blog: Don't DRY Your Code Prematurely](https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html)

## planner programming

[Planner programming blows my mind | Hacker News](https://news.ycombinator.com/item?id=39444282)
[Planner programming blows my mind](https://www.hillelwayne.com/post/picat/)

## pointless projects

[Ask HN: What is the most useless project you have worked on? | Hacker News](https://news.ycombinator.com/item?id=39942397)

## programming community

[Life of a Software Engineer](http://lifeofasoftwareengineer.tumblr.com/)
another reactions tumblr related to Software Development
:star:

[daily.dev](https://daily.dev/)
The Homepage Every Developer Deserves
daily.dev is the fastest growing online community for developers to stay updated on the best developer news. 

[devRant](https://devrant.com/feed/top/all)
fun community for developers

[Programming Praxis](https://programmingpraxis.com/)
A collection of etudes, updated weekly, for the education and enjoyment of the savvy programmer
[ProgrammingPraxis (Scheme exercises)](https://programmingpraxis.com/contents/chron/)

[GOTO](https://blog.gotocon.com/)
Created for developers, by developers, GOTO Conferences are focused on bringing the best minds in the software community and the most interesting topics to light.

[Coderwall](https://coderwall.com/)
programming tips / learn something new

[Sonkeng Maldini/Best-websites-a-programmer-should-visit](https://github.com/sdmg15/Best-websites-a-programmer-should-visit)
Best websites programmers should visit
:fire:

[Stack Exchange](https://stackexchange.com/sites#technology)
All technology related sites on Stack Exchange

[Methods & Tools](http://www.methodsandtools.com/mt/download.php)
magazine about software development & testing with free content.
[Partner websites](http://www.methodsandtools.com/network.php)

[Vinh Quốc Nguyễn](https://betterdev.link/)
Better Dev Link collects links around the web that aims to help you learn something new

[Stack Overflow](http://chat.stackoverflow.com/)
chat rooms on stack overflow

[Martin Fowler](https://www.martinfowler.com/)
author, speaker, and loud-mouth on the design of enterprise software. Evangelist of refactoring and CI/CD

[/r/programming](https://www.reddit.com/r/programming/)
everything about programming on reddit

[Code Simplicity](https://www.codesimplicity.com/)
Max Kanat-Alexander's Blog. Code Simplicity focuses on the idea of simplicity: simple things, simple thoughts, and simple ideas that can make the world of computing a better place.

[CodeProject - For those who code](https://www.codeproject.com/)
Developer Forum

[DEV Community](https://dev.to/)
Developer Forum

[Blind - Anonymous and Professional Community](https://www.teamblind.com/)
Developer Forum

[The Devs Network](https://thedevs.network/)
Developer Chat

[best-websites-a-programmer-should-visit](https://github.com/sdmg15/Best-websites-a-programmer-should-visit#moocs-for-learning-something-new)

[The Recurse Center](https://www.recurse.com/)

[GitHub - jasudev/FabulaItemsProvider: You can share and communicate with developers around the world through the Fabula app.](https://github.com/jasudev/FabulaItemsProvider)
Share and communicate with developers around the world

## programming events and conventions

[GitHub - RichardLitt/awesome-conferences: :ticket: A list of awesome conferences](https://github.com/RichardLitt/awesome-conferences)

## programming

[Tom MacWright](https://macwright.org/2018/02/08/advice-to-the-newish-programmer.html)
(2018) Advice to the newish programmer

[Shaun Finglas](https://blog.shaunfinglas.co.uk/2016/08/why-you-should-do-code-katas.html)
(2016) Why You Should Do Code Katas

[Ginger Bill](https://www.gingerbill.org/article/2021/02/01/the-essence-of-programming/)
(2021) The Essence of Programming
> Many novices fall into the same trap of not understanding the problem that is trying to be solved, and are too concerned about the implementation. Teaching novices how to think about solving problems is extremely important in improving and honing in the craft.

[Anyone want to know what it's like to work on a real project? : learnprogramming](https://old.reddit.com/r/learnprogramming/comments/116633d/anyone_want_to_know_what_its_like_to_work_on_a)

[Brian Kernighan on “The Practice of Programming” [video] | Hacker News](https://news.ycombinator.com/item?id=40927481)
[Brian Kernighan Reflects on "The Practice of Programming" - YouTube](https://www.youtube.com/watch?v=_QQ7k5sn2-o)

## softtware design

[Alfred Thompson](http://blog.acthompson.net/2013/07/5-programming-mistakes-to-warn-students.html)
(2013) 5 Programming Mistakes To Warn Students About

[George Gritsouk](https://gggritso.com/2014/12/02/code-hierarchy-of-needs/)
(2014) Code Hierarchy of Needs
Maslow would not approve of this.

## software architecture

[Just Enough Software Architecture (2010) | Hacker News](https://news.ycombinator.com/item?id=40691929)
[George Fairbanks - Book: Just Enough Software Architecture](https://www.georgefairbanks.com/book/)

[In Defense of Simple Architectures (2022) | Hacker News](https://news.ycombinator.com/item?id=39440179)
[In defense of simple architectures](https://danluu.com/simple-architectures/)

[Coding the Architecture](http://www.codingthearchitecture.com/)
news & presentations on software architecture
[presentations](http://www.codingthearchitecture.com/presentations/)

[Kate Matsudaira](https://queue.acm.org/detail.cfm?id=2974011)
(2016) Bad Software Architecture is a People Problem
When people don't work well together they make bad decisions.

[Kai Niklas](https://hackernoon.com/38-actions-and-insights-to-become-a-better-software-architect-f135e2de9a1b)
(2018) 38 Actions and Insights to Become a Better Software Architect

[Vijini Mallawaarachchi](https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013)
(2017) 10 Common Software Architectural Patterns in a nutshell

[Michal Ciurus](http://yourcodesucksexception.blogspot.be/2015/01/reusable-software-just-do-write-generic.html)
(2015) Drawing clear lines in software architecture

## software developer influencers

[Jim Willis](https://www.jimwillis.org/)

[iGoPayGO - Tech/Life Blog](https://igopaygo.com/)

## software development

[Unencyclopedia](http://uncyclopedia.wikia.com/wiki/Category:Software_Development)
fake wikipedia articles about software development

[Etcd, or, why modern software makes me sad | Hacker News](https://news.ycombinator.com/item?id=23833362)
[roguelazer's website: etcd, or, why modern software makes me sad](https://www.roguelazer.com/blog/etcd/)

## SOLID principles

[Mark Heath](https://markheath.net/post/stable-tactics-for-writing-solid-code)
(2017) STABLE tactics for writing SOLID code

[Brian Geihsler](http://qualityisspeed.blogspot.be/2014/08/why-i-dont-teach-solid.html)
(2014) Why I Don't Teach SOLID

[Sarah Mei](https://speakerdeck.com/sarahmei/is-your-code-too-solid-with-transcript)
(2015) Slides - Is Your Code Too SOLID? (with transcript)

[Brian Geihsler](http://qualityisspeed.blogspot.be/2014/09/beyond-solid-dependency-elimination.html)
(2014) Beyond SOLID: The Dependency Elimination Principle

[Dan North](https://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong)
Slides - (2016) Why Every Element of SOLID is Wrong by

## undo and redo

[Resolving the great undo-redo quandary | Hacker News](https://news.ycombinator.com/item?id=33560275)
[klonk/TheGURQ.md at master · zaboople/klonk](https://github.com/zaboople/klonk/blob/master/TheGURQ.md)

## unforeseeable constraints

[MS Teams channels cannot contain MS-DOS device names | Hacker News](https://news.ycombinator.com/item?id=37076523)
[Limits and specifications for Microsoft Teams - Microsoft Teams | Microsoft Learn](https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams)

## using computer resources

[Vincent Foley aka vfoley, gnuvince](https://vfoley.xyz/reasonable-use/)
(2021) Making Reasonable Use of Computer Resources
> The fastest option eventually wins. Would your project survive if a competitor came along and was ten times faster?

## variables

[kettanaito/naming-cheatsheet](https://github.com/kettanaito/naming-cheatsheet)
Comprehensive language-agnostic guidelines on variables naming. Home of the A/HC/LC pattern.

## versioning

[Kartik Agaram](http://akkartik.name/post/versioning)
(2017) The cargo cult of versioning

[joelparkerhenderson/versioning](https://github.com/joelparkerhenderson/versioning)
notes and summary of article "The cargo cult of versioning"

[Paul Draper](https://www.lucidchart.com/techblog/2017/03/15/package-management-stop-using-version-ranges/)
(2017) Package Management: Stop Using Version Ranges

[Software Engineering Stack Exchange](https://softwareengineering.stackexchange.com/questions/253306/why-is-build-number-an-abuse-of-semantic-versioning)
Why is build.number an “abuse” of semantic versioning?

[Matthew Setter](https://blog.codeship.com/best-practices-when-versioning-a-release/)
(2018) Best Practices When Versioning a Release

[Graham Lee](https://www.sicpers.info/2018/04/whats-better-than-semver/)
(2018) What’s better than semver?

## api certifications

[Back End Development and APIs Certification | freeCodeCamp.org](https://www.freecodecamp.org/learn/back-end-development-and-apis)

## api differences

[SOAP - Wikipedia](https://en.wikipedia.org/wiki/SOAP)

[Different Types of APIs - SOAP vs REST vs GraphQL](https://www.freecodecamp.org/news/rest-vs-graphql-apis)

[API Integration Patterns - The Difference between REST, RPC, GraphQL, Polling, WebSockets and WebHooks](https://www.freecodecamp.org/news/api-integration-patterns/)

## api

[booknotes/architecture/good-api-design-jb-talk at master · preslavmihaylov/booknotes · GitHub](https://github.com/preslavmihaylov/booknotes/tree/master/architecture/good-api-design-jb-talk)

[How to Design Better APIs | Hacker News](https://news.ycombinator.com/item?id=30647784)
[How to design better APIs](https://r.bluethl.net/how-to-design-better-apis)

[Adam DuVander](https://www.programmableweb.com/news/top-10-api-worst-practices/2012/08/03)
(2012) Top 10 API Worst Practices

[A Primer for Testing the Security of GraphQL APIs | Forces Unseen](https://forcesunseen.com/blog/a-primer-for-testing-the-security-of-graphql-apis#vulnerabilities)

## build a travel app

[GitHub - unseen1980/awesome-travel: Do you want to build a travel app?](https://github.com/unseen1980/awesome-travel)

## functional programming - js

[GitHub - stoeffel/awesome-fp-js: :sunglasses: A curated list of awesome functional programming stuff in js](https://github.com/stoeffel/awesome-fp-js)

## making good software

[How to Build Good Software | Hacker News](https://news.ycombinator.com/item?id=20734384)
[How to Build Good Software](https://knowledge.csc.gov.sg/ethos-issue-21/how-to-build-good-software/)

## object oriented vs functional

[oop - Functional programming vs Object Oriented programming - Stack Overflow](https://stackoverflow.com/questions/2078978/functional-programming-vs-object-oriented-programming/2079678#2079678)

[Functional programming jargon in plain English | Hacker News](https://news.ycombinator.com/item?id=31944352)
[hemanth/functional-programming-jargon: Jargon from the functional programming world in simple terms!](https://github.com/hemanth/functional-programming-jargon)

[Hemanth HM](https://functional.works-hub.com/blog/Functional-Programming-Jargon)
Functional Programming Jargon

[GitHub - xgrommx/awesome-functional-programming: Yet another resource for collecting articles, videos etc. regarding functional programming](https://github.com/xgrommx/awesome-functional-programming)

[15-150: Principles of Functional Programming | Hacker News](https://news.ycombinator.com/item?id=38351195)
[brandonspark.github.io/150/](https://brandonspark.github.io/150/)

[Alex Ott](http://alexott.net/en/fp/books/)
Functional programming books overview

## programming

[Thomas Figg (tef)](https://programmingisterrible.com/post/65781074112/devils-dictionary-of-programming)
(2013) Devil’s Dictionary of Programming

[kevindeasis/awesome-fullstack](https://github.com/kevindeasis/awesome-fullstack)
Learn front-end, middle-tier, back-end tier, algorithms, and continuous delivery

[Andrew Wulf](http://thecodist.com/article/the-biggest-difference-between-coding-today-and-when-i-started-in-the-80-s)
The Biggest Difference Between Coding Today and When I Started in the 80’s

[Sane software manifesto](https://sane-software.globalcode.info/v_0/)
While very opinionated, it's an interesting list of practices for software developers, about safe code, collaboration, reproducible builds, modularity, architecture, testability, etc.

[thoughtbot/guides](https://github.com/thoughtbot/guides)
A guide for programming in style.
[Thoughtbot's playbook](https://thoughtbot.com/playbook)
explaining how they build products and run their company

[Week 4: Reading list & news to keep up-to-date with Javascript, Python, DevOps, Cloud, Serverless, Blockchain, AI, Big Data, Personal Growth, Startup. - by TPT - HackerNoon.com - Medium](https://medium.com/@thangtp/week-4-reading-list-news-to-keep-up-to-date-with-javascript-python-devops-cloud-serverless-f725a12a1567)
[Week 6: Reading list & news to keep up-to-date with Javascript, Python, DevOps, Cloud, Serverless… - HackerNoon](https://hackernoon.com/week-6-reading-list-news-to-keep-up-to-date-with-javascript-python-devops-cloud-serverless-52ab683be8d8)

[Philip Guo](http://pgbovine.net/programmers-talking-to-beginners.htm)
Programmers: Please don't ever say this to beginners ...

## software design

[Formal Methods of Software Design an Online Course by Eric Hehner | Hacker News](https://news.ycombinator.com/item?id=26610221)
[FMSD](https://www.cs.utoronto.ca/~hehner/FMSD/)

[Nathan Coulter (Poor Yorick)](http://wiki.tcl.tk/8602)
(2018) Tips for writing quality software.
[Web archive](https://web.archive.org/web/20170630183457/http://wiki.tcl.tk:80/8602)

[stanislaw/SoftwareDesignHeuristics](https://github.com/stanislaw/SoftwareDesignHeuristics)
heuristics found to be useful in software engineering practice. We call “heuristics” everything that helps us to write better code given we keep them in mind.

[Big Design Up Front (BDUF)](http://c2.com/xp/BigDesignUpFront.html)

[GitHub - rafaels88/software-development-resources: Curated list of Software Development resources](https://github.com/rafaels88/software-development-resources)

[AlexSabourinDev/software-development-resources: Collection of links to great software development resources!](https://github.com/AlexSabourinDev/software-development-resources)

[GitHub - luvuong-le/awesome-software-dev: Curated list of documentation, plugins, links and more for software developers](https://github.com/luvuong-le/awesome-software-dev)

[GitHub - thuytrinh/dev-bookmarks: Links to blogposts, books, conference talks and so on regarding software development](https://github.com/thuytrinh/dev-bookmarks)

[GitHub - dkp1903/freesources: Repository of free resources for learning Software Development](https://github.com/dkp1903/freesources)

[Kirupa](https://www.kirupa.com/)

## team programming

[GitHub - mobtimeapp/awesome-mobbing: A list of awesome mobbing/ensemble/team programming resources](https://github.com/mobtimeapp/awesome-mobbing)

## api - FastAPI

[FastAPI Handbook - How to Develop, Test, and Deploy APIs](https://www.freecodecamp.org/news/fastapi-quickstart/)

[mjhea0/awesome-fastapi: A curated list of awesome things related to FastAPI](https://github.com/mjhea0/awesome-fastapi)

## api frameworks

[Learn Playwright & Puppeteer | Checkly](https://www.checklyhq.com/learn/headless)

[An Open-source File Format API Guide For Developers](https://www.fileformat.com/)

## api - GraphQL

[chentsulin/awesome-graphql: Awesome list of GraphQL](https://github.com/chentsulin/awesome-graphql)

[graphql-java/awesome-graphql-java: awesome list of graphql-java related projects](https://github.com/graphql-java/awesome-graphql-java)

[awesome-graphql](https://github.com/chentsulin/awesome-graphql)

[hasura/awesome-react-graphql: A curated collection of resources, clients and tools that make working with `GraphQL and React/React Native` awesome](https://github.com/hasura/awesome-react-graphql)

## api - Heroku

[GitHub - ianstormtaylor/awesome-heroku: A curated list of helpful Heroku resources.](https://github.com/ianstormtaylor/awesome-heroku)

## api - REST api

[How to Consume REST APIs in React - a Beginner's Guide](https://www.freecodecamp.org/news/how-to-consume-rest-apis-in-react)

[GitHub REST API - GitHub Docs](https://docs.github.com/en/rest?apiVersion=2022-11-28)

[The REST API Handbook - How to Build, Test, Consume, and Document REST APIs](https://www.freecodecamp.org/news/build-consume-and-document-a-rest-api)

[GitHub - marmelab/awesome-rest: A collaborative list of great resources about RESTful API architecture, development, test, and performance](https://github.com/marmelab/awesome-rest)

[Kikobeats/awesome-api: A curated list of awesome resources for design and implement RESTful API's.](https://github.com/Kikobeats/awesome-api)

[Vinay Sahni](https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api)
(2013) Best Practices for Designing a Pragmatic RESTful API

[Bill Doerrfeld](https://techbeacon.com/guide-restful-api-design-35-must-reads#.WcVeaYqsgc0.twitter)
(2017) A guide to RESTful API design: 35+ must-reads

## api security

[arainho/awesome-api-security: A collection of awesome API Security tools and resources. The focus goes to open-source tools and resources that benefit all the community.](https://github.com/arainho/awesome-api-security)

[API-Security-Checklist](https://github.com/shieldfy/API-Security-Checklist)
security countermeasures when designing, testing, and releasing your API.

[APISecurityBestPractices](https://github.com/GitGuardian/APISecurityBestPractices)
help you keep secrets (API keys, db credentials, certificates) out of source code.
[Toyota suffered a data breach by accidentally exposing a secret key on GitHub | Hacker News](https://news.ycombinator.com/item?id=33196146)
[Toyota Suffered a Data Breach by Accidentally Exposing A Secret Key Publicly On GitHub](https://blog.gitguardian.com/toyota-accidently-exposed-a-secret-key-publicly-on-github-for-five-years/)

## coding assistants - ai

[How You Can Use AI to Improve Your Code Quality](https://www.freecodecamp.org/news/how-to-use-ai-to-improve-code-quality)

## Electron

[GitHub - sindresorhus/awesome-electron: Useful resources for creating apps with Electron](https://github.com/sindresorhus/awesome-electron)

## frameworks and libraries

[What's the Difference Between a Framework and Library?](https://www.freecodecamp.org/news/frameworks-vs-libraries)

## garbage collection

[The Garbage Collection Handbook, 2nd Edition | Hacker News](https://news.ycombinator.com/item?id=35492307)
[The Garbage Collection Handbook: The Art of Automatic Memory Managemen](https://www.routledge.com/The-Garbage-Collection-Handbook-The-Art-of-Automatic-Memory-Management/Jones-Hosking-Moss/p/book/9781032218038)

[Garbage collection for systems programmers (2023) | Hacker News](https://news.ycombinator.com/item?id=39873692)
[Garbage Collection for Systems Programmers](https://bitbashing.io/gc-for-systems-programmers.html)

## loops

[you-dont-need/You-Dont-Need-Loops: Avoid The One-off Problem, Infinite Loops, Statefulness and Hidden intent.](https://github.com/you-dont-need/You-Dont-Need-Loops)

## programming terms

[GitHub - dephraiim/awesome-developer-dictionary: A curated list of definitions of programming terms.](https://github.com/dephraiim/awesome-developer-dictionary)

## SOLID principles

[SOLID Principles for Programming and Software Design](https://www.freecodecamp.org/news/solid-principles-for-programming-and-software-design)

[jbelmont/pragmatic-programmer-and-clean-code](https://github.com/jbelmont/pragmatic-programmer-and-clean-code)
principles from Pragmatic Programmer and Clean Code books

[What are the SOLID Principles in C#? Explained With Code Examples](https://www.freecodecamp.org/news/what-are-the-solid-principles-in-csharp)

## text cases

[Snake Case VS Camel Case VS Pascal Case VS Kebab Case - What's the Difference Between Casings?](https://www.freecodecamp.org/news/snake-case-vs-camel-case-vs-pascal-case-vs-kebab-case-whats-the-difference)