Dev tip: Learn VIM

So happy that I know how to use VIM. Why? Because sometimes I need to edit files on the remote host.
Maybe your IDE can’t successfully connect to the remote host and you end up with SSH and CLI commands.
My current scenario is implementing a payment gateway and using localhost as host is ignored 😦 I ended up coding on the shared hosting via SSH, but without slowdown thanks to VIM skills.

ss_2017-09-16-10-47-17

Become a better programmer

​Programming is communication, and only the novice would believe it’s just communication with the computer. Not so. Programming has to count what you teach to the biggest computer of them all. All code must be debugged. All code must be maintained. Few programs die with their creator. To be a better programmer, it is imperative to be a better communicator with other humans.

From http://www.yacoset.com/Home/how-to-become-a-better-programmer

Disable PHPCS rule of long condition

I don’t want to comment long code statements end, but PHP CodeSniffer with WordPress Coding Standards does complain with the following error:

End comment for long condition not found; expected “//end if”

So I added the following to the projects phpcs.xml

Sniff source code PHP_CodeSniffer/src/Standards/Squiz/Sniffs/Commenting/LongConditionClosingCommentSniff.php
For more help with PHPCS rules check out Listing phpcs rules and excluding commenting sniff

Spacecraft software

Finally came across an article which describes now is software written for spacecrafts.

In the modern software environment, 80% of the cost of the software is spent after the software is written the first time — they don’t get it right the first time, so they spend time flogging it. In shuttle, they do it right the first time. And they don’t change the software without changing the blueprint. That’s why their software is so perfect.

Software is getting more and more common and more and more important, but it doesn’t seem to be getting more and more reliable.

money is not the critical constraint: the groups $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nation’s most expensive software organizations

From http://www.fastcompany.com/magazine/06/writestuff.html

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