“I want to code!”
It’s the little voice in your head, constantly pestering you to get productive. Replace code with any technology-related hard skill and you have the tech person’s productivity dilemma.
But what does it mean to be productive? What does it mean to be productive as a solo professional?
If you’re a freelance developer and you don’t code, you might feel like you’re not doing the right thing. You might feel like you’re being unproductive.
A lot of mixed feelings may grow on you while working as a junior developer. You have the choice of feeling powerless and less smarter than your peers or full of energy and desire to learn from people who know more than you do. You can look at others, compare yourself to them and grow frustrated, or look up to them and strive to become a better version of yourself.
What follows is a dichotomy between two world views on the same topic.
Part 1: The Pessimistic View There is a lot of personal preference involved, along with ignorance, hype and superficiality.
This is a question I’ve struggled with a lot, while trying to optimise the way I interview people. I don’t want to misjudge people, or evaluate them the wrong way, so I took some time and dug through my head, scoured the Internet for resources and narrowed down to a simple list.
This is not a definitive list, I must state this loud and clear, before you even start reading. None of the points outlined here should be taken in isolation.
If you’re looking to revamp your website and you’re serious about this, you probably found mentions of static site generators, static sites and the JAMStack, on the Internet.
Unfortunately, for every article that tries to explain what are the benefits of using a static site generators, there are other 10 explaining why static sites are not good.
In theory: HTML, data and CSS are served from the same place So Adrian, what’s a static site and why do I need one?
Updates Added more explicit usage of Array.prototype.slice.call(arguments). Thanks @gabriel for commenting and providing feedback. Added resources section with useful links.
Most software developers know that keeping hardcoded strings in your code is bad form. For the most part of our working life, we pester our colleagues to extract stuff in variables, make strings constants, so on and so forth.
Text/translation file management became an interesting topic for me in the second year of my software development career. I was building apps that had a lot of repetitive text and I was frustrated because I couldn’t use the same approach I had with my code, that of extracting strings into constants.
The gist was that some malicious third party was exfiltrating NPM auth tokens that it would probably later use to infect more packages in a ripple-like manner.
What’s even funnier is that while I was listening to Ryan Dahl’s 2018 JSConf presentation, I heard him complain about a similar hypothetical situation with ESLint, namely, that it could take over your computer, due to Node’s non-restrictive model with filesystem and network access.
On Thu, July 12 2018 at 1:17PM GMT Andrei Mihailov — @pronebird reported the following issue with the eslint-scope module: Virus in eslint-scope?.
The gist of it is that there was some malicious code added to the module’s codebase and the affected version was 3.7.2. I’m saying it was because the ESLint team took it head-on and got to the bottom of the problem in record time — Thank you!
I recently had a discussion with an off-shore team mate who was supposed to add a new environment variable to a client-side app and re-deploy it. He had some trouble doing this, and after talking to him and illustrating how frontend apps use env vars in contrast with Node.js APIs, he finally understood the nuances
His misunderstanding was about the way Webpack manages environment variables. Being an ops person, he assumed that environment variables work the same way they do for our Node.