@rolfen
Nothing here yet.
Nothing here yet.
No blogs yet.
That is true. Sadly, I feel some programmer (me) go into programming because it's the only way to express this or have some freedom in automating things. People are often hostile to change and automation, however they let programmers sit in a dark corner and "do their thing".
Never ever, ever, ever check out the "Help" drop down menu. I want to tell them: That thing IS FOR PEOPLE LIKE YOU , you know? I guess some persons prefer to let others do their self-help for them. Oh and something else, people who keep telling me how much of a genius I am while I fix their computer. Probably because: If I'm a genius then they feel better (ego-wise) about not finding their way around the computer. They think that stroking my ego will somewhat facilitate me giving them free help with their computer stuff. Anyway I don't appreciate such compliment, a simple thank you would do.
Write really simple code. Simple does not mean short. Sometimes it's better to be more verbose and lay out the steps and variable names clearly. In other words it's not simple to write simple code. I also write incrementally, making sure everything works solidly as I go. I also try to keep dependencies inside the code at a minimum, and expose various low-level functionality, so that I can test and experiment and get a better understanding of what is happening. A debugger can help too. What I don't like about a debugger is that it's like being on tracks and only being able to go forward. At one of my jobs I got into arguments with another developer because he followed the philosophy that "everything must be private" (except what needs to be used). I follow a different philosophy to make my software easier to diagnose. Formal testing is good. However quick and dirty assertions can also do the job in some cases. Despite that, sometimes I run into hard-to-track bugs. They are often caused by complexity in whatever the code is interfacing with, for example, the DOM. My philosophy is about keeping complexity under control - keeping things simple and transparent. That includes minimizing side effects. Side effect are evil. We have many of these in CSS (eg: oveflow:hidden affects floats and sticky positioning). I guess that pushes me towards functional programming.
I come from a country where you can go to a shop and get any software cracked for less than $1. As I was growing up, original software was an oddity. Now I try to get legit software if I can. For example I paid $30 for my copy of Windows. It's better morally and from many other aspects. However if I can't afford it, and if I can't find an acceptable free alternative, then I will reluctantly tolerate cracked software. But I keep striving for a legit alternative. Piracy is not evil. Digital is all about ease of copy and communication. You can't enjoy the advantage of that, but then not expect people to use that against at some point, or have to deal with the downsides. However it's the attitude of getting it for free just because you can and not caring about how the software is done and how people who spend time and effort to make that software that you're using, how they get their fair share back - it's that attitude that I don't like about piracy.
Even if you can't pass an argument, this is a big step forward. For all the CSS frameworks, where you'd do something like <p class="grid-1 col-m bg-2 wd3 pd-m fs-1"> and the semantics go out of the window - with @apply I can use semantic class names such as <p class="important"> and then map .important to all the CSS framework visual classes in the stylesheet. Presumably I could do that without needing a pre-processor, keeping a lean workflow and preserving ability to modify the stylesheet directly from Chrome Devtools.