For me recently, I've been reading Julia's posts, and they've got some great content in them. She has some great posts about working remotely, like this one here, where she details both the hardships and the benefits of working remotely, which gives those who haven't done work remotely, or even have with or without struggles, some powerful insights into the reality of remote work.

This one, for sure:

Gregg

@greggawatt

Every time you want to get mad at someone who maintains an open source project, remember this image:

21:52 PM - 20 Sep 2017

624013116

Another one was when I was trying to learn about designing a plugin architecture for .NET, and I found a very informative tutorial about the topic complete with code samples that was close to my use case. I was amazed at how the author figured all that stuff out when I knew I wouldn't have been able to if I didn't find his article. At the end of the tutorial was his bio, and it said he codes during the couple of hours when his small town gets electricity. I was awestruck.

These instances remind me of my privilege. That no matter how hard things may seem for me, I have no excuse to slack off.
They remind me to be empathetic in all of my dealings, because I have no idea of the battles other people are going through.

Here are some quotes that I have been keeping in mind for a long time. I've been glad for the 2 about documentation whenever I had to go back to a project I didn't think I'd see again, and the last one helps when I'm debugging.

"Document unto others as you would have them document unto you."
-- Kreitzberg & Schneiderman, The Elements of Fortran Style

"Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live."
-- Martin Golding

"Computer system analysis is like child-rearing; you can do grievous damage, but you cannot ensure success."
-- Tom DeMarco

"If your project doesn't work, look for the part that you didn't think was important."
-- Arthur Bloch

Gilles Deleuze & Felix Guattari's magnum opus Capitalism and Schizophrenia (I'm still working through volume 2, 1000 Plateaus -- it's incredibly dense stuff) has had an enormous impact on how I think generally, to say nothing of its applicability to software development. D&G discuss the construction of communication, psychology, and politics in terms of machinic assemblages and operations, developing models from the bottom up in a counterpoint to the top-down imposition of structure and taxonomy which characterizes Western philosophy and sociology from Aristotle through Levi-Strauss.

Since, per Mel Conway, we are condemned to reproduce the communication structures of our organizations in our software architectures, a methodology for reducing those communication structures to localized patterns within the broader organizational context of human society gives us a much wider view of what's possible. Some of the concepts they explore are already visible in the technological sphere: the rhizome they discuss in 1000 Plateaus can be recognized in many distributed systems, for example.

For me, it was Hackers: Heroes of the Computer Revolution and the Jargon File it the 1980s anonymous-FTP version.

They showed there's a mindset to computing, a culture that I found appealing. Anyone who has seen the line If you can't be a good example, be a horrible warning and remembered with a piteous laugh a point where someone's catastrophic error will be in their memory forever will remember why you should always mount a scratch monkey.

Computer Culture in 2018 is not the same as in 1988, and new histories and new dictionaries should be written, and are. But this is what made me begin to think that making electrons dance is where I should spend my time.

For me, it was a life style "concept".

I've been day dreaming about traveling since I was young(er), it wasn't until a couple of years back that I discovered the term "digital nomad", which is people that work remotely permanently, so they get to travel often. From that moment on, I started joining digital nomads groups, learning more about remote only companies, and just trying to connect with other people with the same life style.

This also pushed me to add more front-end tools to my skill-set because I learned that I would have better chances as a front-end or full-stack dev, so I did.

Now I'm trying to get myself "out there", that's why I built my first portfolio and shared my process right here on dev.to I did it with the solely purpose of sharing what I learnt, but I never thought it would open other doors for me.

The biggest impact had "Clean Code" by uncle bob aka Robert C. Martin.

If I would nail it down to one thing, it is the comment of Ward Cunningham in the first chapter:
"You know you are working with clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem."

As simple as it sounds, it was a revelation for me.

My manager at my second programming job who's attitude was something along the lines of "just do it". I know it sounds silly, like a Nike commercial. I took it to mean, "I know you can do this, so just do it.". The thing is, I didn't use this wisdom right away and passed up many opportunities in the past because I always doubted my competencies.

Nowadays, when I doubt myself (happens often still, Imposter syndrome anyone?), I just think of what he said and I just do it. 👟

And here's an example of following that advice so that you know this isn't just a feel good puff piece comment 😜

ℕ𝕚𝕔𝕜 𝕋𝕒𝕪𝕝𝕠𝕣

@nickytonline

@_esausilva @seanfitzg @housecor Most of my career has been in the .NET ecosystem doing full-stack during parts of my career. I dropped it completely in 2015 and just went full JS/Node/TypeScript/React. Best decision of my life and I didn't need to take a paycut.

16:29 PM - 04 Mar 2018

01

Nothing is too hard. You can learn everything. In this case we are talking about code but whatever it is you want to learn or understand, if you break it into smaller pieces then you find that every individual chunk is easy to master or understand. If it isn't, simply split that part up in pieces again.