Here’s a tip on good documentation: try to write the documentation first. Use it as your planning process, to spec out exactly what you’re going to build. Show the code to people (on GitHub or on a mailing list or on lemmy or whatever), get feedback, change the documentation to clarify any misunderstandings and/or add any good ideas people suggest.

Only after the docs are in a good state, then start writing the code.

And any time you (or someone else) finds the documentation doesn’t match the code you wrote… that should usually be treated as a bug in the code. Don’t change the documentation, change the code to make them line up.

1. Write down who your customers are.
2. Write down what problem your customers have, which can be solved with your product.
3. Write down how your product can solves the problem.
4. Figure out how you can achieve that goal (this needs to be separate to step 3 - you’re essentially tackling the same thing from a different perspective… helping you see things that might not be visible from the other one).
5. Anything that does not bring your product closer to the goal(s), remove it from your product.
6. Anything that would bring you closer, but isn’t achievable (not enough resources, going to take too long, etc), remove those as well.

Those are not singular items. You have multiple customers (hopefully thousands). Your customers have multiple problems your product can solve. Actually solving all of those problems will require multiple things.

If that list sounds functional, that’s because good design is functional. Aesthetics matter. Why do you choose a black shirt over an orange shirt with rainbow unicorns? Take the same approach for the colours on your app icon. Why do you choose jeans that are a specific length? Take that same approach for deciding how many pixels should separate two buttons on the screen.

You said you struggle with looking at a blank page. Everyone does. If you follow the steps I outlined above, then you won’t be working with a blank page.

For edge cases where you need the power of a programming language in your config system, use something like PKL.

Sure - for example we migrated all our stuff from MySQL to MariaDB.

It was completely painless, because all of the source code and many of the people who wrote that code migrated to MariaDB at the same time. They made sure the transition was effortless. We spent a months second guessing ourselves, weighing all of our options, checking and triple checking our backups, verifying everything worked smoothly afterwards… but the actual transition itself was a very short shell script that ran in a few seconds.

I will never use a proprietary database unless it’s one I wrote myself and I’d be extremely reluctant to do that. You’d need a damned good reason to convince me not to pick a good open source option.

My one exception to that rule is Backblaze B2. I do use their proprietary backup system, because it’s so cheap. But it’s only a backup and it’s not my only backup, so I could easily switch.

I’m currently mid transition from MariaDB to SQLite. That one is more complex, but not because we did anything MariaDB specific. It’s more that SQLite is so different we have a completely different database design (for one thing, we have hundreds of databases instead of just one database… some of those databases are less than 100KB - the server just reads the whole thing into RAM and slow queries on our old monolithic database are less than 1 millisecond with this new system).

never use anything vendor specific like stored procedures, vendor specific datatypes or meta queries

Yeah we don’t do anything like that. All the data in our database is in a JSON type (string, number, boolean, null) with the exception of binary data (primarily images). It doesn’t even distinguish between float/int - though our code obviously does. All of the queries we run are simple “get this row by primary key” or "find all rows matching these simple where clauses. I don’t even use joins.

Stored procedures/etc are done in the application layer. For example we don’t do an insert query anywhere. We have a “storage” object with simple read/write functions, and on top of that there’s an object for each model. That model does all kinds of things, such as writing the same data in different places (with different indexes) and catching “row not found” failures with an “ok, lets check if it’s in this other place”. That’s also the layer we do constraints which includes complex business rules, such as “even if this data is invalid — we will record it anyway, and flag it for a human to follow up on”.

The next step is to implement things like this:

https://github.com/WebAssembly/tool-conventions/blob/main/Coredump.md

After that, all we need is a rich ecosystem of libraries in other languages. It’s still a fair way off, but it’s coming.

Is there some huge benefit that I’m missing?

For example I recently fixed a bug where a function would return an integer 99.9999% of the time, but the other 0.0001% returned a float. The actual value came from a HTTP request, so it started out as a string and the code was relying on dynamic typing to convert that string to a type that could be operated on with math.

In testing, the code only ever encountered integer values. About two years later, I discovered customer credit cards were charged the wrong amount of money if it was a float value. There was no exception, there was nothing visible in the user interface, it just charged the card the wrong amount.

Thankfully I’m experienced enough to have seen errors like this before - and I had code in place comparing the actual amount charged to the amount on the customer invoice… and that code did throw an exception. But still, it took two years for the first exception to be thrown, and then about a week for me to prioritise the issue, track down the line of code that was broken, and deploy a fix.

In a strongly typed language, my IDE would have flagged the line of code in red as I was typing it, I would’ve been like “oh… right” and fixed it in two seconds.

Yes — there are times when typing is a bit of a headache and requires extra busywork casting values and such. But that is more than made up for by time saved fixing mistakes as you write code instead of fixing mistakes after they happen in production.

Having said that, I don’t use TypeScript, because I think it’s only recently become a mature enough to be a good choice… and WASM is so close to being in the same state which will allow me to use even better typed languages. Ones that were designed to be strongly typed from the ground up instead of added to an existing dynamically typed language.

I don’t see much point in switching things now, I’ll wait for WASM and use Rust or Swift.

The big difference is Memcached is multi-threaded, while Redis is single threaded.

That makes Redis more efficient - it doesn’t have to waste time with locks and assuming the server isn’t overloaded any individual operation should be faster in Redis. Potentially a lot faster.

But obviously by sharing the load across threads as Memcached does, and that cant theoretically allow higher throughput under high load… if your task is suited to multithreading and doesn’t involve a shedload of contested locks.

Which one is a better choice will depend on your task. I’d argue don’t limit yourself to either one, consider both, pick the one that aligns best with your needs.

Unless of course the corps use “fuck you” money to kill redis.

I doubt the corps are angry at redis. They just don’t like the new terms.

The “mega-corps” have enough money that there’s zero chance this is a money issue. It will be about control.

They don’t want Redis to dictate terms over the software running on their servers. No amount of money will change their mind on that - they wouldn’t accept the new terms if redis offered to pay them billions of dollars.

have there been any improvements in this area?

Um… what rock have you been living under?

For simple code generation, I use GitHub CoPilot.

In both cases, I’m essentially writing the code “from scratch” myself every time, but now I can type “write a person class” then “add a name property”, etc. Best of both words - the control of hand written code, and the efficiency of not having to type all that code out.

When your code is really repetitive, you don’t even need to give it any prompts at all. You can usually just start a new empty line and it will guess what line goes there. For example if you have a firstName property, it will predict you’re about to add lastName.

When it’s more complex, for example if I haven’t figured out how to structure the code yet, I use ChatGPT+. That’s more of a conversation approach, similar to bouncing ideas off a colleague… “how would you do this; what about that edge case; etc”.

Also - post it on GitHub. Preferably now while you’ve got people paying attention. :-)

When I’m going through job candidates, nothing gets my attention better than a public GitHub project where a lot of other people have stared/forked/written issues/submitted pull requests/etc. Which means you shouldn’t just post it, you should spend a bit of time maintaining it. Fix bugs, add features, add content (search for treasure?)

But most useful programs we deal with do more than merely verify an input […] We may sum a list of numbers […]

Computers are binary. 1 or 0. Pass through the electrical gate; or do not pass through the gate. That’s the only tool we’ve got to work with and therefore, “sum a list of numbers” is literally implemented as a series of “accept or reject” steps.

Everything above that is a convenient layer of abstraction. Abstraction is there to reduce your mental load while working but it doesn’t always achieve that goal — especially if you don’t know what’s going on underneath.

those projects shouldn’t really exist

You think web browsers should not exist? How do you write Google Chrome, and all of it’s dependencies, in one page of code?

I think you’re miss-understanding the article. Joel didn’t say you should never rewrite an individual component in your code, he was saying you should never throw out an entire project (all of the components) and start from scratch.

He also wasn’t talking about “multiple people and man-years of work”. He was talking much larger projects. How many people have contributed Chrome? Not just direct contributions writing lines of code, but indirect contributions such as reporting bugs or writing documentation on how it works?

If Google were to start over, all of that would be thrown out. It just can’t be done.

All you can really do is what Microsoft did with IE / Edge. Edge was a fork of Chromium which was a fork of WebKit which was a fork of KTHML which was a fork of the KDE HTML Widget. Which dates back to 1996. Internet Explorer started in 1995. Microsoft didn’t start Edge from scratch, they basically shifted their team of developers over to another project that was the same age.

The smaller the project, the easier it is to do a full rewrite but realistically it’s almost never a good idea unless your product is very young.

Replacing code is fine. Replacing an entire product is the mistake.

I thinking of using a VPS to do the actions because it would be running for a while before my debit card gets cancelled.

Your debit card could be cancelled very quickly. But most VPS providers allow you to pay in advance, so you could maintain something like $100 credit with the provider… which goes a long way if they charge $5 per month for example.

this guy says it’s ok that I’m a full stack dev

I’m also a full stack dev - so maybe I’m biased. But I’ll add that there’s definitely a place for specialist work, but I don’t agree, at all, with people who think specialist developers are better than full stack ones.

The way I see it full stack devs either:

• are good enough to be the only type of developer your hire; or
• sit in between specialists and management

Take OpenAI for example. They have a bunch of really smart people working on the algorithm - so much so they’re not even engineers they’re more like scientists, but they also have a full stack team who take that work and turn it into something users can actually interact with, and above the full stack team is the management team. Maybe OpenAI isn’t structured that way, but that’s how I’d structure it.

But most software isn’t like ChatGPT. Most software isn’t bleeding edge technology - you can usually take open source libraries (or license proprietary ones). Let the specialists figure out how to make TCP/IP handle complex issues like buffer bloat… all the full stack dev needs to know is response = fetch(url).

Sure — security is one area where you do need to be a specialist.

I’d say it’s the exception that proves the rule though. Don’t write your own encryption algorithms, don’t invent new auth flows, do hire third parties to audit and test your security systems, etc etc. If you want to specialise in something like security, then yeah that’s something you should study. But at the same time - every programmer should have general knowledge in that area. Enough to know when it’s OK to write your own security code and when you need to be outsourcing it.

For some non-critical stuff you can experiment til you find something that appears to work, deploy it, and fix any issues that might appear. Too much of today’s Internet is done that way, but it really is ok sometimes

For critical work, you can easily apply the same approach but replace the “deploy it” stage with “do extensive internal testing”. It takes a longer and is more expensive, but it does work. For example the first ever hydrogen powered aircraft flew in 1957, was an airplane with three engines and only one of those three ran on Hydrgoen. Almost 70 years of engineering later and that’s still the approach being used. Airbus claims they will have commercial hydrogen powered flights around 2035 and plan to flight test the final production engine next year on an A380 Aircraft.

The A380 has four engines and each is powerful enough to fly safely with only one engine running. In fact, it should be able to land with four engine failures - with a “Ram Air Turbine” providing electricity and hydraulic pressure to critical systems.

The best approach to critical systems is not to build a perfectly reliable system, but rather to have redundancy so that failures will not result in a “please explain” before congress.

In my opinion the best developers are “generalists” who know a little bit about everything. For example I have never written a single line of code in the Rust programming language… but I know at a high level all of the major pros and cons of the language. And if I ever face a problem where I need some of those pros/don’t care about the cons then I will learn Rust and start using it for the first time.

There’s not much benefit to diving deep into specialised knowledge on any particular technology because chances are you will live your entire life without ever actually needing that knowledge and if anything, it might encourage you to force a square peg into a round hole - for example “I know how to do this with X, so I’m going to use X even though Y would be a better choice”.

Wikipedia has a list of “notable” programming languages, with 49 languages just under “A” alone and I’ve personally learned and used three of the “A” languages. I dislike all three, and I seriously hope I never use any of them ever again… but at the same time they were the best choice for the task I was trying to achieve and I would still use those languages if I was faced with the same situation again.

That’s nowhere near a complete list - which would probably have a few thousand under “A” alone. I know one more “A” language which didn’t make Wikipedia’s cut.

The reality is you don’t know what technology you need to learn until you actually need it. Even if you know something that could be used to solve a problem, you should not automatically choose that path. Always consider if some other tech would be a better choice.

Since you’re just starting out, I do recommend branching outside your comfort zone and experimenting with things you’ve never done before. But don’t waste time going super deep - just cover the basics and then move on. If there’s a company you really want to work for, and they’re seeking skills you don’t have… then maybe get those skills. But it’s risky - the company might not hire you. Personally I would take a different approach, try to get a different job at the company first then after you’ve got that, start studying and ask your manager if they can help you transfer over to the job you previously weren’t qualified for, but are qualified now. In a well run company they will support you in that.

As for learning outside of your 9-5… you should spend your spare time doing whatever you want. If you really want to spend your evenings and weekends writing code then go ahead and do that… but honestly, I think it’s more healthy long term to spend that time away from a desk and away from computers. I think it would be more productive, long term, to spend that time learning how to cook awesome food or do woodworking or play social football or play music… or of course the big one, find a partner, have kids, spend as much time with them as you can. As much as I love writing code, I love my kid more. A thousand times more.

Programming is a job. It’s a fun job, but it’s still a job. Don’t let it be your entire life.

Business, money, and interests of managers who have never written code themselves will carry more weight than the results of your research and study of effective programming languages. This is the fucking reality of the industry today!

That is not even remotely the reality where I work. The reality where I work is:

Everyone we have hired, and everyone we plan to hire in the future, is familiar with languages X/Y/Z. Therefore you will use those three languages.

If you want to use a fourth language, first you need approval to train every single employee in that language. To a high level of proficiency. That would take thousands of hours for each employee.