81–90 of 293 posts
One thing that I find sorely missing in many teams is onboarding documentation. So when you come in, document everything that you need to do (required permissions, development environment setup, mailinglists, subscriptions) and how to do it.
Earlier quoted context omitted.
SVN is really heavyweight for branches and tags. It used to take like a minute to branch with SVN but when we swapped to git it took like less than a blink. Also —rebase is way better than merge. I haven’t had to merge git for over 6 months but with SVN I was doing it twice daily, at least.
If you use a repository URL rather than a local filename / dirname in svn copy, it's a purely remote copy and is instantaneous: $ svn copy file:///var/svn/repos/test/dir1 \ file:///var/svn/repos/test/dir1_jira_1886 -m "For bugfix to SERV-1886" http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.htm... https://svnvsgit.com/
Assuming your employees to know everything and not let then learn is a path to your organization's downfall.
Ben Horowitz makes a good case about it in his book The Hard Things About Hard Things
Ex. Company thinks they need more developers to ship on time (you). First, make sure you're getting tickets done and helping them with the metrics they know, then change the process to fix them for good once you have their trust.
If you skip to step 2, you've got someone angsty with a career on the line who 'isn't getting what they paid for'.
On the other hand we also have people come in, help with the current codebase and after a while they make proposals for improvement that are based in reality. These people integrate well and are quickly respected team members.
Earlier quoted context omitted.
+1 for this. Unless you've been hired specifically to help them change their dev practices, I'd go along with what they have until you've got some understanding and reputational-clout to start suggesting such huge changes to how everyone works. Rocking up and on day one start asking people to change their development practices (particularly around branching policy which is something very contentious and/or strict eve…
The fact that process is off in the first place indicates a deeper problem.
Well, first I gotta rebuild the release process on top of nixpkgs, then, after rewriting the core product in rustlang, I can focus on replacing all the developers' macbooks with linux machines.
Earlier quoted context omitted.
Chesterton's fence has always bothered me a little because it presumes there will be a sensible explanation for the fence, and that the reason will reveal itself to us if we have the patience and guile to see it. Knowing what I know about how some organizations work, I don't think this is necessarily a safe assumption.
I understood it differently. As in: there is always a reason for the fence but you never know whether it is justified or not without understanding it. Don’t tear down the fence until you understand why it was put there for the wrong reasons.
That's why it's important to start with some testcases of required behavior, and then refactor only code that is supported by tests. Because sometimes the fence is there for a reason, but often it's not.
Earlier quoted context omitted.
See also Chesterton’s fence. You don’t want to change something until you understand why it’s there in the first place. https://abovethelaw.com/2014/01/the-fallacy-of-chestertons-f...
This reminds me of the Joel Spolsky's post on why you should never re-write your code from scratch [1]. The reasoning goes most 'ugliness' comes from bug-fixes that people encountered along the way, and by re-writing that 'two page function' you lose all that accumulated knowledge. In short, the hacks that make us want to rewrite code are there for a reason [1] https://www.joelonsoftware.com/2000/04/06/things-you-sho…
A rewrite will solve it in the short term - until requirements change again.
However, I would much rather apply the new 'hacks' onto the rewritten 10 line function than figure out the original 200 line behemoth.
The first thing I do is work to gain enough political leverage so that I can manage my own time.