Question: If I want to become a Full-Stack Developer, which technology to learn first? Front-end? Back-end? Both?
Measuring developer productivity in 2019
Until I spent the better part of 50 hours writing this guide about measuring developer productivity, I had little appreciation for how far we’ve come in the past four years. If you’re an engineering manager, there’s a growing body of data that suggests you can make a blanket increase in engineering efficacy. If you’re a great developer, you now stand to earn your due. These are exciting times to be programming.
Additional topics covered in the (admittedly a bit too epic) guide:
- Better data, better policies. Examples of how measurement can improve retention, morale, and amount of work completed.
- Best tools for measuring developers in 2019. Three tools available to measure developer performance, and how they differ.
- What makes code measurement possible? What changed that made it possible to measure developer output, when it was long assumed impossible?
- On securing developer buy-in. Addresses the first question asked by many companies pursuing developer measurement: how do I get the team on board?
- Transparency always wins on a long enough time horizon. What can be learned from the past about those who embrace and resist increased transparency?
If you manage developers, would love to hear what you think of this effort? Is it relevant to you? Anything that could make it better?
Evernote QA Report: Merge & Sync
Hi Evernote,
Your sync and merge has long been broken, and I hope to provide you enough detail to get it fixed here. All the below should be reproducible, let me know if you find otherwise.
It starts simple. Create a note in Evernote webview. List some fruits. If you’re anything like me, you probably make a couple lists like this per day. All seems well. Later that day, you remember this list, and have a burning need to add “Starfruit” to it. All looks well?
But things are not so well, because when we return to the webview, there’s some bad news awaiting:
^– Now two notes, instead of one
That’s right, my fruit list has split itself in two lists with edits from desktop and mobile. Similar problems persist as I try to use the document.
Unless one is fastidious enough to sync every note when finished, and then manually sync when resuming on another platform, you are liable (at rate inversely proportional to speed of your internet connection) to soon find yourself with something like this:
Every time I switch devices, I must remember “ensure save,” then pre-sync on the new device (and remember to confirm sync finished). Granted, there are a number of trigger points for syncs, but it’s impossible to be sure which, if any, have triggered/completed. One too-fast move, and I’m back in the ghetto of Mergetown.
I usually don’t even know I’ve been losing list items (to duplicated versions), until I notice the note lags in load/save time. And then I realize there are 10 copies of the list in my note, below the (already long) version I was treating as the “real list.”
I sympathize that getting sync to work reliably across disparate platforms is a hard problem [2]. So why not, instead of fully fixing the sync, just spend a few days fixing the merge?
If you could automatically add new lines to both documents without creating duplicate copies, that would be a good start. If you kept the note differences in the area they were found (not bottom of document), that would help. Source control tools have spent 20+ years building great systems to merge two documents. You can probably crib most of your implementation from a plugin/library in that domain? Or at least mark “duplicate documents” so I know I’ll need to hand merge them?
Thanks for considering these improvements. I take the time to write this because I still believe you’re the best solution in your space. If you could just address this fundamental stuff, I’d reap benefits greater than the (sizeable) time it took to create this report.
[1] Lists featuring fruits.
[2] Albeit the hard problem you ostensibly built your business to solve
Best Linux Git GUI/Browser
Since moving to Linux, I’ve also moved to Git (from SVN) and have found it to be a reliable friend that, as a technology, is a significant step up from SVN. But, as a usable productivity tool, I definitely felt the sting of Git’s “hardcore h4x0r” roots in its lack of a GUI that is in the same league as Tortoise SVN. 
But there is hope. And it comes from the unlikeliest of sources: my IDE, Rubymine.
Rubymine’s Git integration is superb. It supports hierarchical browsing of your current branch, in exactly the manner of Tortoise. It also offers:
- Directory-based, graphical means to be able to revert changed files or directories
- Ability to see a history of changes to a file (and return to an older specific version, if desired) along with one-click access to visual diff
- Ability to mass merge files in different branches by batch selecting them and choosing a merge method (i.e., “Use branch A version” or “Use branch B version”… it also supports manual merging via a graphical merge tool)
- One click comparison of your current file to the current repository file
In a nutshell, nearly all of the efficiencies that TortoiseSVN provided as a graphical source control tool for Subversion, Rubymine provides for Git. With one exception — that I have implored the creators of Rubymine to consider adding — the ability to see the history for a directory (rather than a file) within your project. Knowing the crack team of Rubymine developers, the feature will probably be on the way soon, but even before its arrival, they’ve still managed to build the best pound-for-pound Git graphical interface I’ve been able to uncover.
Git move commit to another branch
Rubymine’s stellar Git integration means that I seldom have to tinker with Git on the command line, but an exception to this is when I switch branches and forget to switch back before making my next commit. D’oh!
The answer is git cherry-pick.
The syntax is simple:
git cherry-pick [commit ID]
You can run “git log” to get the ID of your commit. You can also use a graphical tool like Giggle, which lets you see all commits to all branches.
If you had the misfortune of your checkin not being on any given branch, you can run “git reflog” to see all checkins to all branches, and merge your master branch with the fake branch that your checkin went to. See Stack Overflow for more details on what to do in this scenario.