Jessica Kerr on Git

Git is Hard

Abandon your DVCS and Return to Sanity

"Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. And this is merely going down over time as bandwidth gets ever more readily available. If you work as a field tech, or on a space station, or in a submarine or something, then okay, sure, this is a huge feature for you. But for the rest of us, I am going to assert that this is not the use case you need to optimize for when choosing a VCS. And don’t even get me started on how many developers seem to assume that they can’t get work done if GitHub goes down. Suffice it to say that I think most developers are pretty fundamentally unaware of how to use their DVCS in a distributed manner in the first place."

Also check out:
Why the Heck is Git so Hard?

Git Fundamentals -- RG Edu

Part 1
Part 2
Part 3

Git Gotchas

10 Things I Hate About Git

"The information model is complicated – and you need to know all of it. As a point of reference, consider Subversion: you have files, a working directory, a repository, versions, branches, and tags. That’s pretty much everything you need to know. In fact, branches are tags, and files you already know about, so you really need to learn three new things. Versions are linear, with the odd merge. Now Git: you have files, a working tree, an index, a local repository, a remote repository, remotes (pointers to remote repositories), commits, treeishes (pointers to commits), branches, a stash… and you need to know all of it."

Very well said!

Git

My company is in the process of moving from TFS to Git for source control.  My team is one of the teams getting to enjoy the company Git learning curve.  All of the teams are struggling. Most, but not all of the struggle, is around merges.

I don't think anyone has done a deep dive into solutions yet, thinking we'll just learn it as we go.  Six to eight weeks into this, that approach is failing miserably for my team.

So as my first dive, I posting this here for reference:

Commit Often, Perfect Later, Publish Once: Git Best Practices

Scott McConnell's 10x

On the drive into work today, I was listening to .Net Rocks Show #727  Steve McConnell Studies Development Practices.

I think this is the first I heard of Scott McConnell's blog: 10x Software Development.  As a big fan of McConnell's Code Complete 2, I am interested in checking this out.  I'm familiar with the 10x rule of software developers: the best software developers are 10x better / more product than the worst.  This is certainly true, and it applies to every single field and is probably very understated. For example, Tom Brady is definitely worth more than 10x the worst quarterback in the NFL.  That said Tom Brady is in the 1% of 1% of quarterbacks, so the number of programmers who should be making a million or more a year is terribly small. So while I probably disagree with Scott Hanselman overall on this subject, there is much validity in what he writes here: The Myth of the Rockstar Programmer.

I have certainly met and worked with developers who deserved $200K to $400K a year while the rest us on the team were under $100K.  And as I have improved my skills and knowledge over the years, I would love to be in situations to start earning those numbers, and more.

Fun With Antipatterns

DevIQ Antipatterns 

I admit that one of the big draws of getting in software was not having to deal with people.  But that's just not how life works.  If you want to grow, learn, and advance in your career, you absolutely must interact with people, and interact with them well. For me, one of my big life mistakes is not recognizing other people's perspectives and thereby giving them the respect they deserve.

The advice here in Deadtech's post is rather basic, but so very important:

Lifting the Curse of Knowledge

Beck Design Rules

I could not agree more with Kent Beck's list: BeckDesignRules.

Design Priorities

1. Passes the tests
2. Reveals intention
3. No duplication
4. Fewest elements

Craftsmanship

This weekend's gems:

Craftsmanship and professionalism.


One's tools and frameworks should not be their architecture.


And when you need performance, you need to know your framework inside and out:

Writing High-Performance .NET Code