It’s 2014 All my colleagues are writing their Bachelor’s Degree paper in LaTeX1. Or MSWord… 🤮
I’m doing it in Markdown, mostly because LaTeX looks too verbose for me. And I’m not that smart anyway.
I was never the brightest bulb in the chandelier, to begin with.
So, back to LaTeX: too verbose, too many keywords.
Looks like the type of thing highly skilled academics use to flex their look-at-how-many-format-specifiers-I-can-pull-from-memory muscles.
“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.
Last week I saw this very interesting Twitter thread, about CI/CD strategies for multiple teams.
The question was whether or not one should go on a centralized, or a decentralized strategy for setting up continuous integration for multiple teams inside the same organization.
This article tries to distil the key points of that discussion.
The centralized model You might be right, thinking that going centralized is the best choice. Everybody uses the same infrastructure, the same technologies and future, cross-cutting projects can look like a breeze.
I’ve been working a lot with microservices in the past couple of years. It is during this time that I found how many issues can arise from putting an accent on delivery while disregarding architecture.
This is why I decided to create MONOLITHSPL/T.
I want to help businesses migrate their monolithic Node.js applications to a microservices architecture, improve the quality of their products as well as their overall delivery. My goal is to provide clear, actionable steps, to move away from poor architectural decisions made under pressure.
I receive a notification from Quora. Someone had asked me to answer this question. At first, I was tempted to give the “Learn the language basics and then go for libraries” sermon. But I stood and thought for a moment. Since the time I used to obsessively preach that, I went through a lot of teams, mindsets and technology stacks. I saw that neither the teams or the businesses needed people who were experts at language fundamentals.
Recently I took a lot of interest in Golang. I was listening to the GO TIME podcast — GoLand IDE and managing Gopher Slack and there was a lot of chatter about IDEs vs. editors. What sparked my interest was the discussion around working with Git from the command line vs. using the IDEs built-in tools. This is what motivated me to write about the workflow I have with Git.
I published a similar article in 2015. Back then, I was using GTD, Evernote and a lot of tools that have since disappeared from my stack. This is not an update to that article, it is a competitor. I will update it in the days to come as it currently serves only as a placeholder.
For some time I’ve been thinking of ways to better organise my article ideas. I want to get my content out there, to you, as fast and as often as possible.
I usually keep my ideas in an application such as Apple Notes or Google Keep. I’ve been going back and forth between the two for the past 2 years, and they’re both great tools. The problem is that many ideas die at the idea stage.
Whether you’re a developer, designer or any type of professional in the tech industry, there’s one disease we all fear: change. Technologies, tools, languages, techniques … all of them change literally overnight, sometimes leaving behind disappointed, frustrated people. In this article I plan on describing the actions I take when dealing with the ever changing tech world.
What?! It’s already outdated? Technology changes, you can’t keep up, deal with it!