One year at the helm of Vim

One year ago I started using an old text editor called Vim. I’m happy to say that I’m still sticking with it. I’m now very comfortable with VIM and more empowered translate Ideas into working solutions.

In this year I’ve become accustomed to working the terminal, embracing the VIM way while realizing that that coding is just one part of the challenge.

Not your IDE

Transitioning from PhpStorm, I desired the same IDE-like features in VIM. After multiple config changes and plugin tests, I had an epiphany: VIM is an editor and that’s it. It is one of the tools in your shed. You combine it with other command line tools to empower an efficient workflow. I believe this is key to making the most of VIM.

With this also comes the realization that tabs, though it looks nice, is not the most efficient way to switch between files. A short list of buffers is the way to go. I always close the editor when I’m done with a task and re-open it for the next one. This ensures that all current buffers are closed and I can start with a low memory footprint every time.

Who Uses Caps Lock anyways?

A common thing in the VIM community is to modifying CAPS LOCK key. As a programmer you don’t really use CAPS LOCK, you will mainly use SHIFT for upper case. Some VIM users take CAPS LOCK as an extra escape and others as another CTRL. I have chosen CTRL as many commands require this button, which is awkwardly placed on my Mac Keyboard.

Hard Times are good for you

One of the first things I embraced was Hard mode. With this activated, VIM disables the arrow keys for navigation and stops you from jumping up more than one line at a time (using h,j,k,l). This pushed me to use other movements. I would argue this to be a must for any VIM beginner. You simply don’t understand how powerful these other movements are until you get used to them. It is excruciating in the begging but the benefits far outweigh the cost. After some time I turned this mode off and used “Hard Time” instead, which works the same but is a little more forgiving.

Undo and try again

Practicing all the time is critical to mastering VIM. By practicing, I mean on the Job training, while you’re working and editing. If you find that you did something and it took too long, or you remember a faster way to do it. Stop, undo and redo it in a more efficient way. This more effecient way becomes the default going forward and you save yourself many many seconds in future. Adding all these ups definitely increases your editing speed.

Another note on this is not to worry about the time it takes to add a shortcut to your config files. Every second you shave off your workflow gets multiplied by how many times you have to repeat the same editing tasks and this is a major win!

Trying not to use so many plugins

The VIM plugin echosstem makes it much easier for newbies feel comfortable and for masters to craft the exact experience they desire.

I discovered that plugins can get in the way just as much as they can help. You need to make sure you really need a plugin before installing it. What I do is try to I try to get away without a plugin to see if I cant modify my VIMRC to do the same thing a plugin does. As a last resort, I’ll use a plugin.

Onwards and Upwards?

I would encourage everyone to learn VIM, but honestly but I understand that not every workflow will benefit from being close to the Command Line.

You are not in a mutually exclusive relationship with your editor. Use the one that’s better for the task at hand. I occasionally jump into Atom ( forgive me VS Code champs ). As Daniel Miessler puts it, the content matters more than the editor.

Let’s not allow our tools to get in the way. These are our weapons of mass impact and ultimately only a means to an end.

Imposters handbook: a quick review

A year ago I read the imposters handbook. It seemed like this book was specifically for people like me. The found himself in the same position I was in: Feeling like an imposter.

I read this book a year ago, but it took me this long to write something about it as I was lacking the daily discipline of working on my blog probably related to the same imposter feeling.

I felt like an imposter and, at times, probably still, but I’m way more confident now after I realized that everyone else feels the same way. The book showed me that feeling like an imposter is normal but that it doesn’t mean that you should continuously take the back seat and let another lead the way as you think you don’t belong.

This book is a great starter for people, like me, who did not do a Computer Science degree. It is a basic introduction to many relevant topics, but you may want to dive even deeper into those that you encounter more often.

You will find topics you may never ever need, but it’s simply nice to be familiar with what these are and that you can smile and nod without blatantly faking it.

A year later I notice that version 2, with Scott Hanselman, is out and it looks promising:imposters_handbook_season2Link to Imposters Handbook Season 2

I would encourage anyone working in technology or with an interest in programming to read this. It has certainly given me a great deal of comfort knowing that I can now understand some CS concepts that evaded me in the past. 

a brilliant talk on how to prepare for success

I watched this talk and it answered most of the questions I had about how to succeed and make an impact.

The talk is titled “You and your research/career”, implying your career is something to be studied.

You should watch it yourself, but for me, the main take away is: “Work on important things with important people”.

I hope you learn something that inspires you to take charge of your career. Where do you want to be, who do you want to work with and what kind of legacy do you want to leave behind.

I got this talk from: Must-See Tech Talks for Every Programmer

Programming well with others

I watched a funny but interesting talk about working well with others.

An important take away from this video is:

  • It’s not about how smart you look, but what impact you can make with others

You can find many other great pieces of advice in the video. It is done in a very interesting manner. They’r taking “live” calls!

I got this from Must-See Tech Talks for Every Programmer.

32 and content

Yesterday I turned 32. What an amazing time to be alive. There are so many mountains to climb and challenges to overcome. I have a sense of destiny awaiting while feeling thankful that I have opportunities to reach for things greater than where I come from.

I had no party, no event, not too many people over and it felt libarating. Having the option to choose what to do and then choosing a simple day, with loved ones. Those very close to me. This, in the form of conversations, phone calls and messages. I appreciate the day called birthday and I understand why it’s such an important day to almost every one.

I realise that health is something one takes for granted and that it is one of the biggest blessings in our lives. Without it, nothing works. I’m eternally greatful for mine.

I am a beliver and it shapes every part of my life. I’m thankful for every new year that’s added to my life. I’m so thankful for all the good gifts I have recieved and I’m eternally greaful for salvation and a walk that challenges me to grow.

I hope that this is just the beginning, I hope that my story continues further into the happily ever after. I hope that I grow in character, skill and spheres of impact. I hope to spend more days feeling content and less days thinking about what I do not have. I hope focus on who I’m becoming and not what I’m acquiring.

When are you proficient in a programming language?

Learning a programming language gives you the opportunity to explore other problem domains alongside new approaches to addressing familiar problems.

I write this as I was looking for the answer to exactly this question. There were many opinions that had me confused, some from ancient rockstar ninjas who command CPUS at will and others from earnest people who are also seeking.

Why would one ask such a question in the first place? It seems like the actual issue is 2 fold. For me it is firstly; when can this go on my resume. Secondly and probably more specific to me: when to move on to the next language or skill. When can I check off my to-do list and say that I know a programming language?

After looking at many other ideas, In my opinion: You are proficient in a language when you are able to read, understand and debug code along with deploying to production.

If you can read, write and execute you are well on your way and I would consider this profecient. Beyond this, optionally, persue mastery. Though in order to keep a language on your resume, make sure to continually read, understand and debug.

Link to other opinions: https://softwareengineering.stackexchange.com/questions/154862/at-what-point-can-i-say-ive-learned-a-language