Comment by lkrubner
7 years ago
"Instead of blaming the tools, you (and your team) should probably learn how to use them."
From the essay:
--------------------
And Git is intimidating, not just to non-technical staff, but also to inexperienced programmers. In How To Destroy A Tech Startup In Three Easy Steps I talk about Sital, and his unwillingness to commit things to Git. He was learning a great deal about many other technologies, and he didn’t have any spare energy to learn about Git. He went a month without making a commit, and then he only did so because I insisted. After I put a lot of pressure on him, he got to the point where he would make one commit a day, at night, when he was stopping for the day. He would commit to the master branch, because he was confused how to handle different branches. When there was a merge conflict, I would resolve it for him. We worked together for 6 months, and in that time he learned a great deal about a lot of important topics, but he never really learned how to use Git, because it was a low priority, for both him and our CEO.
> He was learning a great deal about many other technologies, and he didn’t have any spare energy to learn about Git.
Git is something that you can use on almost any project, with any team, at any company. It's something you need to use if you want to contribute to open source. Aside from your programming language of choice, it's probably the second most useful tool you should be learning as a software developer.
You're telling me a developer was too busy learning "other technologies", and in 6 months he couldn't be bothered (or was too afraid) to spend one or two hours going through a simple course about git? By that argument, he probably couldn't be bothered to learn how separate concerns into classes or how to use refactoring or write tests. What other things didn't he have time for? Unwillingness to learn is not an excuse.
> he never really learned how to use Git, because it was a low priority, for both him and our CEO.
I think it was more of a lower priority for your CEO than Sital. Learning git was something that benefited him more than it benefited the company.
I still have issues with your attitude, because it can be applied to anything useful in software development, but management might take issue with. Writing tests? Who needs them? The CEO doesn't care so they're low priority. Refactoring? Waste of time. Management wants shiny features not code quality. Developers have tried really hard to convince management that some overhead is needed to keep the quality high and maintenance easy. Your attitude is the exact opposite.
* Your attitude is the exact opposite. *
You setting your theory against my lived experience. If you want to understand the situation more fully, you can read How To Destroy A Tech Startup In Three Easy Steps:
https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...
I did my best to re-create the extent to which decisions were driven by panic and the pressure of time.
Please note, every company in the world has a finite amount of time, and a finite amount of money. You can argue that a company should hire people with more experience, but people with more experience will be more expensive, so you will end up with less people. Or you can argue that a company should hire more people, of less experience, and then train them. Training takes time, so in this case you are trading time for money.
All of these strategies work, but in different circumstances. In the circumstances that I faced in 2015, described in the book, I advocated for the strategy of less people, of a higher skill level. I was, however, outvoted, which is a reality of corporate life.
It is relatively rare that a company follows an ideal strategy. What I see instead is constant course correction, often with a bit of a lag, so that the company ends up having the ideal strategy for dealing with the situation that it faced 6 months ago, which is not necessarily the ideal strategy for what it is facing now.
Business tends to be chaotic. The Platonic Ideal of computer programming needs to be adjust to the real realities that businesses face.
To be clear, Sital's attitude was a major problem, and myself and co-workers advocated that he be fired. But management kept him on, and I was given the responsibility of covering for the gaps in his knowledge. I was not happy about this, but this is a reality of business: we often have to accept that a decision has been made that we strongly disagree with, and then we need to somehow make the best of it.
Well, I see you're adding more and more constraints to suit your point of view. First you attacked git by pointing out some flaws that were only just about people not knowing how it worked. Then you gave a more specific example, where actually, it was in the company's best interest to hire a novice developer who didn't have time to learn git, because he was pressured into focusing on whatever the CEO wanted. Then you argued that really, companies can't hire good people, or train them, or use good practices and we should just use the path of least resistance. At the end of the argument, it wasn't really about git.
The issue you have with git, is that untrained developers have a hard time using it. Which brings me back to my original comment. It really doesn't take long to train someone to use git. And you can choose whatever flow you want. That's the beauty of it. If the company hires lower skill people, you can just guide choose a branching mode suited for their needs. They don't even need to use branches. Or just teach them to use an UI. But please don't teach them SVN.
5 replies →
> Sital's attitude was a major problem
Would it be the best if Sital never committed his changes? That way he would not be able to hurt your project and you would be able to fire Sital sooner.
1 reply →