Learn every programming language

Great article https://blog.bradfieldcs.com/in-2017-learn-every-language-59b11f68eee on why to learn more programming languages.

Did you know about the existence of brainfuck programming language?

Hello World in brainfuck 😀



Replacing I’m a (PHP, Python, Javascript, C++, etc.) developer with software engineer idea kinda resonates with me. I like it.

The article mentions http://hyperpolyglot.org/ which has a great side-by-side feature comparison of some programming languages.

Signs of a bad programmer

​If your skills deficiency is a product of ineffective teaching or studying, then an alternative teacher is the compiler itself. There is no more effective way of learning a new programming model than starting a new project and committing yourself to use whatever the new constructs are, intelligently or not.

… a good programmer will search for a built-in function that does what they need before they begin to roll their own, and excellent programmers have the skill to break-down and identify the abstract problems in their task, then search for existing frameworks, patterns, models and languages that can be adapted before they even begin to design the program.

… you must have discipline. Being aware of flaws in your plan will not make you more productive unless you can muster the willpower to correct and rebuild what you’re working on.

Imagine your program’s input is water. It’s going to fall through every crack and fill every pocket, so you need to think about what the consequences are when it flows somewhere other than where you’ve explicitly built something to catch it.

From http://www.yacoset.com/Home/signs-that-you-re-a-bad-programmer

Evidence based scheduling by Joel Spolsky

​When I see a schedule measured in days, or even weeks, I know it’s not going to work. You have to break your schedule into very small tasks that can be measured in hours. Nothing longer than 16 hours.

Fix bugs as you find them, and charge the time back to the original task.

from https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/

Painless Software Schedules by Joel Spolsky

​As a rule of thumb, each task should be from 2 to 16 hours. If you have a 40 hour (one week) task on your schedule, you’re not breaking it down enough.

If you have to figure out what subroutines you’re going to write, you are forced to pin down the feature. By being forced to plan ahead at this level, you eliminate a lot of the instability in a software project.

When you first add a task to the schedule, estimate how long it’s going to take in hours and put that in both the Orig[inal] Est[imate] and Curr[ent] Est[imate] columns. As time goes on, if a task is taking longer (or shorter) than you thought, you can update the Curr Est column as much as you need. This is the best way to learn from your mistakes and teach yourself how to estimate tasks well.

Update the elapsed column every day. Updating your schedule daily should only take about two minutes.

Put debugging time into the schedule!

from https://www.joelonsoftware.com/articles/fog0000000245.html

Good software takes 10 years by Joel Spolsky

… ​that’s just the first ten years. After that, nobody can think of a single feature that they really need. Is there anything you need that Excel 2000 or Windows 2000 doesn’t already do? With all due respect to my friends on the Office team, I can’t help but feel that there hasn’t been a useful new feature in Office since about 1995.

So, it takes a long time to write a good program, but when it’s done, it’s done. Oh sure, you can crank out a new version every year or two, trying to get the upgrade revenues, but eventually people will ask: “why fix what ain’t broken?”

slow down, or your existing customers will stop upgrading. They’ll skip releases because they don’t want the pain or expense of upgrading.

from https://www.joelonsoftware.com/2001/07/21/good-software-takes-ten-years-get-used-to-it/