What public figures publish and believe, in their own words.
About this feed
Highlights: posts that did unusually well for the person who wrote them, everything
they published at length, each release and new project, and every belief — at most
two a day from anyone. Day by day, newest
day first; within a day, the people with the most beliefs on this site come first. Nothing
else orders it. Show everything instead.
The quoted blocks are what people actually said; a beneath one is
the belief those words support, in korrents' wording. Nobody here wrote their own page.
Top people are the people in this feed with the most beliefs on this site, then the
most here. Choose an area and the row leads with the people whose beliefs are about it;
tap a face for their feed.
It’s always harder to write software for more specialized hardware. A GPU is pretty generic. If you can’t write an in Nvidia stack, there’s no way you can write a stack for your chip. My approach with Tinygrad is first write a performant NVIDIA stack.
Of course, when you talk to an AI that’s made by a big company in the cloud, the AI fundamentally is aligned to them, not to you. And that’s why you have to buy a tiny box. So you make sure the AI stays aligned to you.
So almost if Codex or copilot are helping you, that actually probably means that your framework or library is bad and there’s too much boilerplate in it.
But the real thing that I want is not something that like tab completes my code and gives me ideas. The real thing that I want is a very intelligent pair programmer that comes up with a little popup saying, “Hey, you wrote a bug on line 14 and here’s what it is.”
I think driving is not tool complete and programming is. Meaning you don’t use the best possible tools to drive. Cars have basically the same interface for the last 50 years. Computers have a radically different interface.
At the same time, in order to reduce the probability of someone intentionally or unintentionally bringing about a rogue AI, we need to increase governance and we should consider limiting access to the large-scale generalist AI systems that could be weaponized, which would mean that the code and neural net parameters would not be shared in open-source and some of the important engineering tricks to make them work would not be shared either.
While we love GraphQL for many use cases, implementing a secure and performant GraphQL API can be tricky and there is a definite cost to requiring it during early prototyping of your app.
RSC is the future of React. The React team has made this very clear and we are lucky to be in touch with their amazing team members to help us along this path.
I know it doesn’t click with everyone, but as someone who lives in their browser most of the day, I really need one that’s fast, reliable, and a joy to use, and Arc checks all those boxes for me.
The app costs a few dollars up front and then has an optional subscription for unlimited requests, but I would recommend going directly to OpenAI’s developer dashboard, creating your own account, and copy/pasting your own API key into Petey.
It simply cannot be the case that we're willing to give up a decade or more of hardware performance just to make programmers’ lives a little bit easier.
This experiment started from the observation that despite being critical for the functioning of the Internet—and, by extension, the economy—the role of open-source maintainer has not yet found a sustainable manifestation.
The temptation to enshittify is magnified by the blocks on interoperability: when Twitter bans interoperable clients, nerfs its APIs, and periodically terrorizes its users by suspending them for including their Mastodon handles in their bios, it makes it harder to leave Twitter, and thus increases the amount of enshittification users can be force-fed without risking their departure.
The Linux Programming Interface by Michael Kerrisk – an exhaustive reference on how Linux works. There are about a million chapters, but every individual chapter is pretty short and I find it quite readable.
Hell even worse, a lot of the libraries that underpin the fabric of what we all call the digital economy have trouble getting enough money to pay for food.
We are not suppliers. All the people writing and maintaining these projects, we are not suppliers. We do not have a business relationship with all these organisations.
I spent the last few weeks reading Template Metaprogramming with C++ by Marius Băncilă. It is currently 50$ on Amazon. Though, technically, the book is about advanced 'template' techniques, it is much more broad and practical. It is one of the 'good programming books'. If you are an experienced C++ programmer, you should give it a peek
Our Tendency shapes every aspect of our behavior, so understanding this framework lets us make better decisions, meet deadlines, suffer less stress and burnout, and engage more effectively.
Sure, electric bikes aren't cheap. But I believe they're a rare object to be well worth the cost. This in spite of their annoying flaws, their often bad software, their defective geometries. Because they open the world.
The Vanmoof is much smarter — the brain and software within it are refined, the app good, the acceleration curves smooth — but the bike is all custom components, and they aren't the highest quality at that.
Programming, of course, is forgetting, but we need to at least try to be aware of the costs of the abstractions we choose and consider who it is that ends up being forgotten.
In my opinion the root cause of this bug is that when a white american developer sees a terminal they immediately interpret it as this idealized cartesian plane where they can lay out any writing they want in neatly-spaced characters that behave in "predictable" ways (in other words, behave exactly like English).
I have argued that the probability of a bad equilibrium is only marginally influenced by the level of debt, but can be much reduced by a contingent rule making the primary balance react to an increase in debt service.
Multipliers are likely to vary a lot over time and space, but the bulk of the evidence is that they are different from zero, positive for spending, negative for taxes, and that they are stronger when monetary policy does not or cannot react to fiscal policy.
Modern browser with split-screen functionality. Helps organize different work contexts more efficiently. Yeah I know, I know. It's a Microsoft product.
Code has mass. Every additional line of code you don't need is ballast. It weighs your codebase down, making it harder to steer and change direction if you need to.
Climate change is the existential crisis of our time. We need more ideas and progress in every sector, including software-based approaches to preventing emissions and sequestering carbon.
Free software is designed to be used commercially, but you have to do it correctly. This is a resource which is made available to companies who want to exploit it, but they must do so according to the terms of the licenses.
I used to think that this was unequivocally a win for open source. That to fight for attention with the commercial alternatives, we had to adopt the commercial playbook. Now I think it’s at the very least a mixed blessing.
We as a profession misunderstand and misuse the concept of backwards compatibility, both upstream and downstream, by focusing on narrow legalistic definitions instead of outcomes.
a good software project tries to break downstream as little as possible, and when we do break downstream, we should do our best to make the breakage obvious and easy to fix.
WinMerge just gets better and better. It's free, it's open source and it'll compare files and folders and help you merge your conflicted source code files like a champ.
Other software I use to build stuff includes Netlify for hosting, GitHub for version control and collaboration, SVGO and TinyPNG for optimization, Kap for screen recording, GoatCounter for analytics, and Chrome and Firefox dev tools.
Other software I use to build stuff includes Netlify for hosting, GitHub for version control and collaboration, SVGO and TinyPNG for optimization, Kap for screen recording, GoatCounter for analytics, and Chrome and Firefox dev tools.
Other software I use to build stuff includes Netlify for hosting, GitHub for version control and collaboration, SVGO and TinyPNG for optimization, Kap for screen recording, GoatCounter for analytics, and Chrome and Firefox dev tools.
But nobody will ever get to the billions of representative miles necessary to say anything compelling about expected safety until after they actually deploy their fleet.
The fast route — venture capital funded — is going to impose constraints on your business that will ultimately make it difficult to remain true to your open-source mission.
Selling is hard. Building a repeatable model with a team that you attempt to rapidly scale is even harder. Fortunately, Mark Roberge, who was one of the very first employees at HubSpot shares the processes and frameworks he used to build a sales machine. If you like the principles behind Lean Startups, then his data- and experiment-driven approach to sales will be very appealing.
Want to know the story behind how Salesforce was built? This is that story in founder Marc Benioff's own words. At times I found him overly prescriptive without an appreciation for his unfair advantages he had (getting to start it while having a big salary at Oracle, having $6Mn in "bootstrapped funding", etc). However, he also helped pioneer the cloud and SaaS as a business model, so there are many great lessons to glean if you're building a high-growth SaaS business.
Breville Bambino Plus Espresso Machine and Baratza Encore ESP Pro Coffee Grinder - Developers need coffee, and I like mine HOT. The integrated milk steamer is a must-have, and since this machine takes freshly ground beans, the grinder allows me to tweak the grind size for perfect single dose espresso shots.
To read papers, I use Adobe Acrobat Reader and sync them in the cloud. This lets me read, highlight, and sync my papers across devices (work laptop, personal laptop, iPad). Instapaper does the same for online articles.
To read papers, I use Adobe Acrobat Reader and sync them in the cloud. This lets me read, highlight, and sync my papers across devices (work laptop, personal laptop, iPad). Instapaper does the same for online articles.
Firefox is a great browser with some awesome tools, plus strong privacy. I use Edge when I need to test on Chromium; I don’t even install Chrome on my personal machines.
The data paint an incredible picture: One that shows the price of solar electricity from utility-scale systems dropping by anywhere from 30-40% with each doubling of cumulative solar deployment.
Because arguably the majority of our time working on software is not spent writing it: we're reading code, trying to understand it, slightly tweaking and editing it.
I'm currently running macOS Mojave, backed up with both Time Machine and SuperDuper to an external drive and BackBlaze to the cloud. Overkill maybe, but after a major drive crash a few years ago, I'm not taking any chances.
I've run all my sites on Jekyll and GitHub Pages for a while now. I have found it easier to manage than WordPress (particularly as I know next to nothing about databases),
When I'm writing articles etc that need to be shared with an editor, I typically write in Microsoft Word. I hate all word processing software, and anyone who insists that Google Docs is so much better than Word is a liar.
Firefox is my favorite web browser. This is in large part due to Tridactyl, an add-on that makes the interface Vim-like, which makes the interface far more capable.
It's basically the Vim of audio editing software, so I wouldn't recommend it if you don't have the time and energy to heavily invest in customizing it for your workflow, but I can move like lightning in this thing.
Sizzy is a cool browser specifically for responsive design. It lets you view all of the breakpoints for a site at the same time and also does a good job auto-scaling fixed size viewports to fit whatever window size you're using.
here's some notable software that I use daily. I also maintain an active list here. Fish Shell. Micro text editor. Toot Mastodon client. cmus audio player.
here's some notable software that I use daily. I also maintain an active list here. Fish Shell. Micro text editor. Toot Mastodon client. cmus audio player.
Work that’s too fine, too early commits everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge.
Shaping is primarily design work. The shaped concept is an interaction design viewed from the user’s perspective. It defines what the feature does, how it works, and where it fits into existing flows.
Speed and reliability are often intuited hand-in-hand. Speed can be a good proxy for general engineering quality. If an application slows down on simple tasks, then it can mean the engineers aren’t obsessive detail sticklers.
Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow.
I love software that does this: Software that unbloats over time. This should be the goal of all software. The longer it’s around, the more elegant it should become. Smooth over like a river stone.
Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance.
I'd say the central piece of software I use is Dropbox, which syncs subsets of my entire filesystem across all of my computing devices: iPhone, iPad, laptops, and desktops.
I’ve seen recurring comments to the effect of “This is great, but individuals aren’t where the money’s at, it’s companies”, which is a position I’ve also previously taken.
The only reason it isn't higher on this list is that the content is a bit specialized and narrowly focused on the landing and the software and adjacent topics; it's definitely one of my favorite books here.
Did you know, the tests you write with react-testing-library look almost identical to the tests you write with vue-testing-library. Magic things happen when you don't test implementation details. :)
If you were as I was and are contemplating diving into Rust, a couple of pieces of advice, for whatever they're worth: I would recommend getting both The Rust Programming Language and Programming Rust. They are each excellent in their own right, and different enough to merit owning both.
Let me close by offering a sincere thanks to those in the Rust community who have been working so long to develop such a terrific piece of software – and especially those who have worked so patiently to explain their work to us newcomers.
not only did I buy the canonical reference (The Rust Programming Language by Steve Klabnik, Carol Nichols and community contributors), I also bought an O'Reilly book with a bit more narrative (Programming Rust by Jim Blandy and Jason Orendorff).
What should we do about open source maintainers not getting the funding they need? It’s a very real problem, and one Kevin has explicitly asked us to talk about before we criticise his solution to it.
But the Commons Clause doesn’t present a solution for supporting open source software. It presents a framework for turning open source software into proprietary software.
This is about the craft of software development, and thinking about how to produce good code. As the name suggests, it's a very pragmatic and hands-on book. It really helped me on my journey as a software engineer, to be able to write quality code day in and day out, and be confident that it's going to work correctly.
Another similar and also interesting book is Concepts, Techniques, and Models of Computer Programming, which explains all the models of computer languages and how they fit together.
But this book is very useful for somebody like me, with experience in high-level engineering languages, like VBA, PHP and R. They're incredibly useful languages, but ones that computer scientists generally disdain, because they're not theoretically pure or beautiful. This book shows you how languages can be constructed. The most valuable thing it gives you is confidence and knowledge to go and create your own programming language.
The right to fork is still critical as an implied threat to keep the system in check. But major political forks aren’t as common, and certainly not as top-of-mind, anymore.
In order to understand Marx, you really do need to know something about Hegel. It's a mistake to think you could read Marx as a scientist or an economist without understanding the Hegelian framework of his thought. That's why I chose to begin with Hegel.
Google Chrome: What's a Web Developer without Google Chrome browser? The first thing I do with Safari is to get Google Chrome and install the latest version.
Awesomely creative think-piece. 40 very short fictional stories about what happens when you die. The framework is inspiring for anyone: coming up with 40 different answers to any one question. But they’re also just brilliant ideas and powerful little fables. I just read it a 2nd time and love it even more now.
This book had a big impact on me as young software developer. It was the first time I saw in print the principle "bugs that go away by themselves come back by themselves". It's something that I've often repeated to myself, and my team, if nothing else but to prepare us mentally for when that hard bug does come back. The chapter advising developers to "proactively step through your code during development, don't wait for the bug report" improved my productivity enormously, and I followed the practice for many years.
The Unix Programming Environment is a book you can't read too soon. It's something I wish I'd come across years before I actually did. An authoritative and comprehensive manual for using Unix as a programmer, it clearly explains concepts such as inodes, hard and soft links, system calls, and the power of joining programs together via stdin and stdout. By the time I came across this book I already knew these concepts, but had never studied them before in one place, and in such a coherent manner.
Becoming a Technical Leader is both an interesting and subtle book. At times it feels like a self-help book, at other times a Machiavellian explanation of how programming teams really wok. But in the end it's sincere and mature, and wants to help. Weinberg's introspective style will appeal to many programmers, and it appealed to me. This book is useful because it talks about many of the practical issues of becoming a technical leader or manager within a team of developers — and from many unexpected viewpoints.
What can one say about this book, that hasn't been said already? Perhaps this: that of all the books written about programming, this has the highest information density of them all. And yet it's so pleasant to read. There is something about the tone of this book — the way the authors speak to you. They explain everything, and yet never seem patronizing or condescending. The joy they feel for their craft — it really does seem like this book comes from a time when programming was a craft — is unmistakable. Many of today's programmers — web developers, iOS developers, front-end engineers — may have no need to ever read this book. But for those who have not done so, and really want to improve as programmers, work through this book. It's a rite of passage.
It covers concepts at a high level and hits the major points, but it's lacking in technical depth, details on how things work, advanced topics, and clear exposition.
Podcast. Yes, yes, yes! We live very distracted lives and most of our working days are filled with shallow tasks and interruptions. Although programmers get the importance of flow, it’s so hard to achieve. Our environments don’t support it, and shallow work is just easier. The book makes a compelling case for why we should double down on deep work, and offers some practical strategies for achie…
It's well studied in a number of other contexts including healthcare, aviation, mechanical engineering, aerospace engineering, and civil engineering, but we don't see it discussed in the context of software.
as an application developer, writing to files safely is hard enough that it should be done via some kind of library and/or database, not by directly making syscalls
For programming, I spend most of my time in vintage Microsoft Visual C++ 6, released in 1998, because the workflow is superior to newer Visual Studios for me.
The known connection between geometry, logic, topology, and functional programming suggests that the connections between representations and types may be of fundamental significance.
And if I’m allowed to extrapolate, a clear path is now laid out towards a future where the steps to go from sketch to design to implementation are greatly more accessible to everyone with an idea.
The main issue, however, is that underestimating the size of the state space is actually very easy. In other words, it’s difficult to come up with the complete list of questions that your UI needs to answer.
I use Outlook to maintain my calendar and address book. I hate that program, too, but I can't find anything else that lets me sync locally to my iPhone without going through the cloud.
I still use Eudora for my e-mail (version 7.1, not the one based on Thunderbird), because I don't want my mail living in the cloud. I'd upgrade to something newer and better, but there isn't anything newer and better.
Since the project I work on is a command-line tool that is primarily implemented in C, I use the usual CLI development tools, e.g. make, gcc, gdb, etc. The documentation is in AsciiDoc.
I however recently started to experiment with crouton, which allows me install a chrooted Ubuntu (or other variants of Linux) on a Chromebook and I can use GnuCash there. So far, this set-up seems to be working well enough for me, so I may be able to lose the Vizio someday.
It's true that controlled studies only tell you something about a very limited set of circumstances, but the fix to that isn't to dismiss them, but to fund more studies.
A flexible enough system that can share rendering code between browser and server and provides tools for progressively loading scripts and styles will probably eliminate the colloquial distinction between websites and webapps. Both are reigned by the same UX principles. A blog and a CRM are fundamentally not that different.
JavaScript allows us to mask network latency altogether. Applying this as a design principle should even remove most spinners or “loading” messages from your applications.
Then comes Prince, which converts HTML and CSS to beautiful PDF files. (Disclosure: I'm the chairman of the board of YesLogic, the company behind Prince.)
Back in 2009, my music player of choice was Amarok 1.4. This was by far the best music player I had ever used on Windows, Mac, or Linux, especially when combined with the wonderful ReplayGain plugin.
I write code in Atom, the text editor we've been working on for six years at GitHub. It's based on Chromium, so to customize it you can inspect it just like any other web element.
My development environment is managed by Boxen, Homebrew, and my dotfiles. I'm feeling good about all of that, which wasn't always the case if you were a Ruby developer five years ago.
For photo editing I use GIMP, and if I need something deeper, my wife has a Mac with Photoshop, Illustrator, and software to make movies and burn DVDs.
I admit a bit guiltily that for previewing and designing CSS, I turn to MacRabbit's CSSEdit 2.5, a version that's no longer shipping, as its functionality was absorbed into the company's Espresso Web site development software.
For text editing that is not specifically related to programming the Mac and iOS, I rely heavily upon BBEdit, where I do most of my Python, HTML, JavaScript and PHP editing.
I've been recording electronic music using strange software like WolframTones, which lets you 'evolve' pieces using cellular automata, or QuasiMusic which generates sounds mathematically from quasicrystals - patterns that almost repeat but never quite do.
I spend a lot of time writing papers and preparing talks with free software: emacs for text editing, LaTeX for typesetting, and IrfanView for editing images.
I spend a lot of time writing papers and preparing talks with free software: emacs for text editing, LaTeX for typesetting, and IrfanView for editing images.
The last important piece of software I use is Counter-Strike. I've been playing Counter-Strike for well over 25% of my life now. These days I specifically play a modification of the game called Gun Game. It's ridiculous and mindless. The reason I play it, and the reason I say I "use" Counter-Strike is that you can get in 5 minutes of stress relief with Gun Game without having to commit to playing for 30 minutes or an hour. Each round lasts only around 5 minutes, you have fun, then you get back to being productive.
It's hard to learn, but Logic is a beautiful piece of software. It's also hard to learn how to record using real studio equipment, so it should be no surprise that learning how to record with professional quality music software is difficult.
The field of programming need to see a renaissance in fundamental reinvention, just as it did in the 1950s when programming machines using levers and buttons was replaced by programming machines using textual sequences of computer commands.
I use my knitr package to generate reports directly from code (literate programming); the "reports" may include homework, blog posts, websites, papers and books.
Combined with git, the best source code control tool I've ever used (and I've used them all), I can set up a bare machine in a matter of minutes and have full access to all of my kernel trees, emails, and development tools.
I've gradually became a big fan of Haskell; I feel it makes me write much more solid code that is much easier to maintain and refactor. But the best part is there are seemingly no end of things to learn in the Haskell space.
Computer: My only machine is a 13" MacBook Air. I switched my daily partner from Linux boxes to Mac laptops 5 years ago. I love Macs since they work well with both UNIX tools and Adobe software.
I use Flixel and NAPE to make web games, and I use Cocos2D and Box2D to make iPhone games, and in both cases I can just implement my ideas without worrying about the boring, arcane aspects of programming.
I use Flixel and NAPE to make web games, and I use Cocos2D and Box2D to make iPhone games, and in both cases I can just implement my ideas without worrying about the boring, arcane aspects of programming.
At home on the Mac, I use a nice program called Arq, which also backs up to S3. It is not open-source, but all of the data is stored on your own S3 buckets, and there is an open-source program for retrieving it, so you aren't locked in.
I also have a dedicated Arch Linux laptop, currently a Lenovo x220 Tablet PC with capacitive & pen touch screen. I run a lot of customizations to take advantage of the hardware.
Textpad - text editing software that I do most of my writing and development in. It gets out of the way when you need it but has great features like regular expression search/replace (so handy!) and search-in-files, which I use quite a bit too.
I use Arq for backups, LastPass for passwords, Chrome for my browser and have four users set up inside Chrome to handle business and personal account separation.
Things remains my to-do app, especially now that the cloud sync is in public beta. I like the way it lets me organize to-dos into different projects; when you have a lot of projects, that bit of separation is key.
I really like the fullscreen text editor Dark Room for taking notes, and I've found I find it a lot easier to get to sleep since I started using F.lux.
There are still a few things that aren't feasible to be implemented in Emacs Lisp yet, but Conkeror lets me maintain the runtime-modifiable paradigm in the browser.
I do as much as I can in GNU Emacs since it pains me to use monolithic software that can't be modified at runtime. Emacs is the closest you can get on a modern OS (except maybe for Smalltalk) to the dream of the fully-dynamic Lisp Machines of the 80s - you can alter nearly any aspect at runtime without recompiling or even restarting.
My only regret in switching from Linux to OS X is giving up the raw efficiency of tiling window managers like ion. ShiftIt makes up some of the difference.
My main desktop at home is 2005 Mac Mini running Linux. I upgraded the RAM and added an Intel SSD to it. It's very old and slow but it's pretty quiet and I'm too lazy to replace it.
When I was at Vertigo Software I was quite tied to Visio, but at Geoloqi I'm predominately on a Mac, so I've switched over to Omnigraffle for wireframing.
GitHub is an amazing place, product and breeding ground for ideas revolving around software development, created by the ever so humble Chris Wanstrath (and Tom Preston-Werner).
TextMate has been my companion in all weathers during many years, but when I quit Spotify to join Facebook and had a long vacation in between, I decided to put some effort into writing a "better" programmer's text editor which I call Kod, released in December 2010.
Adobe Photoshop gets some use, mostly when my business partner sends me designs and buttons and such to turn into markup and CSS, but also when I want to goof around a bit with images or process screenshots for my writing.
I use Lynx for moment-to-moment browsing. It's all-text, fixed font, black-on-white, no JavaScript or Flash or blinking or borders… it's just more comfortable to read blogs and news articles this way.
I also spend a lot of time in Notepad++, which I use both as a code editor and my note-taking application; my file of ideas is literally just a text file that remains permanently open in a background tab.
My home and work setups are identical: early-2008 octocore Mac Pros, each with two 24" Dell monitors, 6 GB of RAM, two-disk software RAID-0 with a third disk as an internal Time Machine, the Microsoft Natural Ergonomic Keyboard 4000, and the Magic Mouse.
The sequel, Rocket Surgery Made Easy, is a terrific, short, concise, fun guide to running simple "hallway" usability tests to improve the usability of your software and websites. Highly recommended.
I am using a Lemote Yeelong, a netbook with a Loongson chip and a 9-inch display. This is my only computer, and I use it all the time. I chose it because I can run it with 100% free software even at the BIOS level.
I've tried LaunchBar and a few others, but I always come back to Quicksilver. I want my launcher to appear, react to my input, and disappear instantly. Quicksilver has always felt the snappiest to me.
I use a 3.2ghz 8-core Mac Pro with two 30" cinema displays. I can't say enough good things about having two 30" cinema displays. I use every pixel of each when I am programming and designing.
I use SnagIt and Camtasia Studio to take screenshots and produce screencasts; I use SyncBack Free to back up my files to an external drive, and I use Cygwin to do command line work.
And amazingly enough, if you insist on looking at the world through a bucket of shit, the world starts to look an awful lot like a bucket of shit: by the end of the book, Rosenberg has left the lay reader with the sense that we are careering towards some sort of software heat-death, after which meetings-about-meetings and stickies-on-whiteboards will prevent all future progress.
For a majority subset of software, called “information software,” I argue that interactivity is actually a curse for users and a crutch for designers, and users’ goals can be better satisfied through other means.
When the software designer defines the visual representation of her program, when she describes the pictures that the user will interpret, she is doing graphic design, whether she realizes this or not.
Why are updates to my reading list so rare? Because computers change a lot in 10 years, but people don't. To make better software, you need to understand how people work, and that is what the books I recommend tend to focus on.
The vast majority of software development projects will fail: they will overrun their schedules, produce substandard results, or sometimes not even finish at all. This isn't an argument; it's a statistical fact.
I challenge any developer to pick up a copy of The Mythical Man Month and not find this tale of a long-defunct OS, and the long-defunct team that developed it, startlingly relevant.
Designing software is difficult, to be sure, but designing a door is difficult too. The nuances of design extend into every object you touch, whether it's some hot new SQL engine, or a humble shoe.
Steve McConnell's Code Complete 2 is the Joy of Cooking for software developers. Reading it means that you enjoy your work, you're serious about what you do, and you want to keep improving.
Rapid Development isn't about rapid development. It's about the reality of failure. The vast majority of software development projects will fail: they will overrun their schedules, produce substandard results, or sometimes not even finish at all.
Any good developer knows that they can code the same stuff with huge variations in lines of code, furthermore code that's well designed and factored will be shorter because it eliminates the duplication.
A korrent is a belief a person has stated in their own words: one
sentence stating the claim, backed by a quote and a source, kept at
korrents.com.
Under a name here, the quoted block is what they actually said.
The korrent beneath it is the claim those words support, in
korrents' wording — tap it to see the record, its source, and who
else holds it.
Nobody here wrote their own korrents. They are compiled from public
statements, and a person can change their mind, which is recorded too.
About the English under a post
Some people here publish in a language other than English. Where they
do, this site shows a machine translation beneath the post, in
this typeface — the site's own, not theirs.
The post itself is never changed, moved or hidden: what is set in the
serif above is exactly what the person published, and it is what to
quote them on. A translation can be wrong in ways that matter,
especially about tone.
Only the post's own words are translated. A quoted post, a linked
article and a belief on korrents.com
are left in their original language.