“Turning vim into an IDE through vim plugins” is yet another take on customizing the Vim text editor and making it into a full featured IDE. Most of these things were possible for years (I even had my own blog post on the subject), but with every version of Vim it gets easier and easier to setup a more advanced developer environment.
“Vim after 15 years” is yet another one of those “my Vim configuration review” posts by someone who has been using Vim for 15 years or so.
As someone who is also a long time Vim user, I have to say it’s quite common to review your configuration once in a while and remove some outdated bits which made it into plugins and Vim core, update plugins to newer versions, and replace plugins with newer alternatives.
I’m still surprised by the number of people who don’t get this … Meetings are important and sometimes people have to be interrupted. But just keep in mind that the 5 minute chat will probably throw off people for an hour.
TreeSheets is an Open Source cross-platform free form data organizer, which can replace a variety of other tools, like spreadsheets, mind mappers, outliners, project management tools, text editors, notes applications, and even small databases. It works on Linux, Windows, and Mac, and looks very interesting. Have a look at the screenshots for some of the things that it can do.
What drives me crazy is that ever since my first job I’ve realized that as a developer, I usually average about two or three hours a day of productive coding. When I had a summer internship at Microsoft, a fellow intern told me he was actually only going into work from 12 to 5 every day. Five hours, minus lunch, and his team loved him because he still managed to get a lot more done than average. I’ve found the same thing to be true. I feel a little bit guilty when I see how hard everybody else seems to be working, and I get about two or three quality hours in a day, and still I’ve always been one of the most productive members of the team. That’s probably why when Peopleware and XP insist on eliminating overtime and working strictly 40 hour weeks, they do so secure in the knowledge that this won’t reduce a team’s output.
I knew about git interactive staging for a while now, but I’ve never really used it. Most days I work on a single feature or bug fix at a time and can commit sequentially, one change after another. For an occasional mess, I found git interactive staging user interface too be too cumbersome.
The last couple of days at work were quite chaotic, with me jumping from one thing to another, and I decided to master that feature once and for all. Looking for a better tutorial, I came across this blog post, which covers the interactive staging, but also provides a much simpler approach – “git add –patch“.
It’ll take some practice to get it into my finger memory, but I think I’m settled now.
Here’s something I wanted to get into for a while now, but haven’t had the time yet – switching the monitoring / alerting system from server-oriented to business-oriented. The gist of the story is:
If it’s not actionable and business critical, then it shouldn’t ring.
The article has some statistics and summaries as well. The reasoning behind the switch is obvious, but it’s good to have it formulated:
After a few months, I can tell reducing our alerting rate should have been a top priority before things got out of hands, for a few reasons.
- Constant alerts prevented the team to focus on what was important. Being interrupted even for things that can wait for a few hours lowers our productivity when we work on things that can’t wait.
- Being awaken every night, several times a night exhausts a team and make people less productive at day, and more prone to do errors.
- Too many off hours interventions cost the company a lot of money that could be invested in hardening the infrastructure or hiring someone else instead.
Jason Fried has an excellent write-up on the pros and cons of using group chat for the team communications, and some of the ways to make it better. We use HipChat in the company and while it’s vital to our operations and I can’t even begin to think how we could do what we do without it, it does have some negative side effects – exactly as James describes them.
The most valuable advice out of that long article is this one (I’ve heard it before a few times, but it’s worth repeating):
Think about it like sleep. If someone was interrupted every 15 minutes while they were trying to sleep, you wouldn’t think they’d be getting a good night’s sleep. So how can getting interrupted all day long lead to a good day’s work?
Slashdot runs a thread on “Are Remote Software Teams More Productive?“. The original post links to a few research references that, unsurprisingly, show how expensive interruptions are to programmers, and how unprepared we are, as an industry, to deal with this problem. I particularly liked a rather in-depth look at the issue in “Programmer Interrupted” article.
Like you, I am programmer, interrupted. Unfortunately, our understanding of interruption and remedies for them are not too far from homeopathic cures and bloodletting leeches.
Here are a few points, if the article is too long for you to handle:
Based on a analysis of 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio and a survey of 414 programmers (Parnin:10), we found:
- A programmer takes between 10-15 minutes to start editing code after resuming work from an interruption.
- When interrupted during an edit of a method, only 10% of times did a programmer resume work in less than a minute.
- A programmer is likely to get just one uninterrupted 2-hour session in a day
And also this bit on the worst time to interrupt a programmer:
If an interrupted person is allowed to suspend their working state or reach a “good breakpoint”, then the impact of the interruption can be reduced (Trafton:03). However, programmers often need at least 7 minutes before they transition from a high memory state to low memory state (Iqbal:07). An experiment evaluating which state a programmer less desired an interruption found these states to be especially problematic (Fogarty:05):
- During an edit, especially with concurrent edits in multiple locations.
- Navigation and search activities.
- Comprehending data flow and control flow in code.
- IDE window is out of focus.
Overall, not surprising at all, but it’s nice to have some numbers and research papers to point to…
The long story short: I love i3. It’s awesome. But I still switch back to MATE once in a while.
What’s good about i3? It’s super fast. Even faster than a pretty fast MATE. It’s keyboard navigated, and it only takes about a day to get used to enough keyboard shortcuts to feel comfortable and productive. It’s super efficient. Until I tried i3 I didn’t recognize how much time I spend moving windows around. It is unexcusable amount of time spent needlessly.
What’s bad about i3? It’s low level. In order to make it work right with multiple screens, one need to get really familiar with xrandr, the tool I last used years ago. If you are on a laptop, with a dynamic setup for the second screen (one monitor at the office, one at home, and an occasionally different project at client’s premises), you’ll need a bunch of helper scripts to assist you in quick change between these setups.
And then there is an issue of flickering desktop. The web is full of questions about how to solve a variety of flickering issues when using i3. The one that I see most often is the screen going black once in a while. Sometimes it takes a second to come back, sometimes a few seconds, and sometimes and it doesn’t come back at all. The more windows I have, spread across more workspaces, with more connected monitors – the more often I see the issues. It’s annoying, and it’s difficult to troubleshoot or even report, as I haven’t found a pattern yet, or how to reproduce the problem.
With that said though, I am now about 80% time using i3. I like the simplicity and efficiency of it. It’s so good, that I work better even without a second monitor. But when I do need a second monitor (paired programming, demos, etc), or when I have a projector connected, I switch to MATE. That’s about 20% of my time.