Earlier quoted context omitted.
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…
People have been measuring the cost of refactoring versus rewrite from scratch, but the results are, as so often in the industry of software development mostly ignored. Anyway, there (obviously) is a tilting point.
Ask HN: What is the first thing you implement at a new company?
251–260 of 293 posts
Re: Ask HN: What is the first thing you implement at a new company?
#252(front end js) My new favorite tool is the ridiculously named husky package, which allows for configurable git hooks inside of package.json. Specifically what I'm doing now is precommit eslint and prettier, and prepush test:all i.e. people on my team will be unable to commit if they fail lint and unable to push if they fail unit tests. There's of course positives and negatives to this approach but the former signific…
Re: Ask HN: What is the first thing you implement at a new company?
#253One of the first things I do, as a sysadmin/devops person, is to look at how "easy" it is to communicate. In other words, does this department have group chat, how easy is it to add documentation, how do I tell who is on call, am I being told things face to face or am I being walked through existing documentation? This is related to a lot of deep issues in operations or development, I feel. If the only documentation…
For example suppose you encounter documentation by word documents in windows shared drive and an set up but not really used confluence (so we don't need to think in this example about setting up a system technically, but how to make people use it).
Re: Ask HN: What is the first thing you implement at a new company?
#254Earlier quoted context omitted.
Or you rewrite it to be more flexible and seriously think about what if's eg what if sales tax was changed in the middle of a month/billing period. This is a real example at one job in the UK on budget day I used to listen the budget speech live in case it had any impact on the system I worked on.
I worked with one guy once where he wanted the "ultimate flexibility" and every data model object basically became a database table with the columns 'key' and 'value'. Trying to think of everything ahead of time has its own problems...
Each record type and field in that record had its own entry in a MIDAS table so you could process say TELEX records differently to Email, Data etc.
Re: Ask HN: What is the first thing you implement at a new company?
#255Earlier quoted context omitted.
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…
That article by Joel Spolsky was one of the few I can't fully agree with. The greatest successes of my career have often been in creating "next generation" implementations of software using newer or better technology and designs. Those re-implementations have resulted in very significant performance and productivity gains. While rewriting things from scratch can definitely be a naive impulse, there are times when it'…
Re: Ask HN: What is the first thing you implement at a new company?
#256For the first month or so I take a very humble listening position, even if I immediately see things I want to fix. More often then not, there is a background and a history to things that could lead to a) my “fix” being unnecessary and/or ill-informed and b) friction with the rest of the team because here comes a whippersnapper upending all our stuff. Process and code fixes are _much_ easier once you have good rapport…
We've got a new member on our team (from a different team within the company) who within his first week is already trying to shake things up with "fixes" Its driving me a little crazy. He is more senior than us, but doesn't have any of the context of why we do things the way we do He'll explain things to us we already know, and propose solutions to us we tried months ago that didn't/don't work After getting a little…
It might not, but that's not necessarily a bad thing.
Personally speaking, I've been on both sides of this conversation. A number of years ago, I joined a company and I tried to shake things up with fixes. My initial ideas lacked the context, I didn't understand the constraints, and I certainly trivialized some important aspects of what was going on. Some people were patient with me and focused on explaining the unique context and constraints. Fortunately for me, I took the time to listen to them and I was in a much better position to offer up fixes.
Some of my fixes were good and well received, and others not so much. Typically, I found my ability to create positive change was strongly correlated to me taking the time to ask people questions, heeding their warnings, leveraging their unique insights and giving their contrasting opinions credit.
When I hired a technical lead for my team, the shoe was on the other foot and when he joined. He offered a lot of very good ideas to shake things up and fix things. When he asked for permission to do these things, I made it a point to never say no, but to take the time to explain the context and constraints. His first few months weren't tremendously productive because we subjected him to the pain of the thing he was going to eventually automate. Eventually, I was given the opportunity to let him loose and give him the freedom to do what he thought was important. I'm glad we did, because he ultimately created some really good tools. More importantly, he was able to prove me wrong about some of the problems I thought were unique to us.
I guess what I learned from it was the importance of directing people's energy. As you already know, it requires the patience to continuously engage in conversations to make sure that self-drive isn't wasted. These days, I'm a lot more appreciate of someone joining the team has a strong locus of control.
If you really want him to become part of the team, try distributing the task by encouraging other team members to help him. He'll be a lot more receptive to listening to your unique constraints if it's coming from people who are trying to help him.
Re: Ask HN: What is the first thing you implement at a new company?
#257Earlier quoted context omitted.
People have been measuring the cost of refactoring versus rewrite from scratch, but the results are, as so often in the industry of software development mostly ignored. Anyway, there (obviously) is a tilting point.
But what are the results?
Re: Ask HN: What is the first thing you implement at a new company?
#258Ain't no such animal.
Re: Ask HN: What is the first thing you implement at a new company?
#259Earlier quoted context omitted.
In that vein, I invariably have one massive commit on every project to remove trailing whitespace first. That way when my well-behaved editor removes them with each commit, it's not littering up the diff.
My opinion is that every team member should have the same editor with the same settings. The settings should be easily accessible from Confluence or a similar knowledge base.
If you're not pairing, it seems like a move with a poor payoff for its cost. Sure, make sure everyone has identical code style in their auto-formatter, but let them pick their own editor.
Re: Ask HN: What is the first thing you implement at a new company?
#260Basically, when I ask for a role, whereby I expect to be placed in charge of the project, I expect exactly that. Not some fluffy title, with a cushy salary. I expect to be able to destroy the scrum process, hang the scrum master. Toss agile in the garbage. Ask the product owner what they actually want. Do that, in about a month. Finish the project 6 months ahead of schedule single-handedly, because web apps are fucki…
You sound like a horrible coworker and employee.