I request good ergonomic equipment so I don't needlessly work in pain. Otherwise I'm pretty flexible.
Ask HN: What is the first thing you implement at a new company?
121–130 of 293 posts
Re: Ask HN: What is the first thing you implement at a new company?
#122Earlier 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.
If the process is 'off' around branching policy, there may actually not be a problem. It's certainly possible the new dev prefers a different branching policy simply because that fits with what they are used to. There may be reasons, and good ones, for what may at first appear like poor git practice. Or it may be a problem, but a new dev should at least give it enough time to determine there is no reason things are this way before advocating change.
Re: Ask HN: What is the first thing you implement at a new company?
#123#Tl;dr; Build relationships first, then build a reputation for your expertise, then implement changes.
Just for context, I’ve been working as a professional software developer for 22 years, but I let my career and knowledge stagnate until 2007 and became an “expert beginner” (https://daedtech.com/how-developers-stop-learning-rise-of-th...). I relaunched my career 11 years ago this month. So, how I’ve approached “what to change”, changed over the years...
2007 - started working at a small company. I took the job because they were looking for high level junior developers and were transistioning from VB6 to C# and they had a C++/MFC framework. It was the perfect position for me. I was really good at both their old technology and I was just getting into C#.
I didn’t try to change anything. I took the job to get some real world modern development experience and soaked everything in.
2011 - that company went out of business but by then, I knew C#, I could talk the talk about modern software engineering practices but I still needed more experience. I got a job at a Fortune 10 (at the time) company and learned how modern large software teams and organizations worked and was there to learn, not to change things. I took what I learned and leveraged it and my by then 20 years of on paper experience to get a job where they wanted someone to make significant changes to a slow moving dysfunctional software development department....
Again: My goal wasn’t to make changes, it was to keep my head down, not ruffle feathers and learn.
2014 - With both my manager’s and his manager’s blessing, I along with the other developers they hired, went in and started trying to make changes in the CI/CD process, getting rid of some bespoke custom libraries that could be implemented better using popular Nuget packages, and changing the testing process like bulls in china shop completely disregarding the feelings of the old guard. Eventually the old guard won, pushing both managers out and leaving the new hires without any cover.
Lessons learned: Build relationships first, respect the past decisions that got the company to where it is, and remember one of the “Laws of Power”, “Law 45: Preach the Need for Change But Never Reform Too Much at Once”. Try to win people over based on building relationships.
2016 - I started working at a new company with the official title of “Team Lead” where I was brought in to modernize the development department. I learned my lesson, first I built relationships, I respected the work the team did, engendered respect, and earned the loyalty of the team. Even though I had role power, I realized that wasn’t going to be effective without the relationship power.
I implemented version control, a real CI/CD process, automated testing, documentation standards, fought to reduce needless meetings and fought for the “40 hour work week”.
2017: I got another job at a small company as “just” a senior developer and an equal on paper. I quickly started building relationships and proving my expertise. I have far more influence to make changes based solely on doing that than I have ever had before.
Automation is always my hobby horse. First I implemented a sane CI/CD process and configuration management.
The next thing I’ve worked on is getting rid of single points of failure in both systems and people - I’m encouraging cross trainings.
Re: Ask HN: What is the first thing you implement at a new company?
#124Earlier quoted context omitted.
If it's well tested a straight re-write is the right call. It's when there isn't good test coverage where things ossify.
In theory. In practice, the code will often have corner case behaviours that eludes any of the tests, yet are still important. As an aside, as I understand it, refactoring was popularised as a response basically to this conundrum - it's a technique for reorganising code without changing its functionality. So you can gradually "rewrite" your two page function without losing the accumulated knowledge.
Unless we really stretch the word "refactor", my "in practice" is different than yours. I've done plenty of re-writes that fixed more unknown bugs than re-opened previously solved ones.
Re: Ask HN: What is the first thing you implement at a new company?
#125Documentation is my biggest thing. I start with onboarding, CI/CD. Then start adding api and archicture documentation. This forces me to learn, and ensure I digest well enough to explain to other people.
Once that's done I start adding unit tests, monitoring, and additional dashboards.
Re: Ask HN: What is the first thing you implement at a new company?
#126Earlier quoted context omitted.
More likely the hacks are there because requirements changed and the software wasn't initially built to be flexible enough to support change. 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.
In my experience, it's extremely difficult to know which particular lines of code are obsolete. This becomes even more difficult as a codebase ages and is worked on by more contributors. Add on another exponent for every business stakeholder that has a hand in defining the business rules—especially if you have requirements coming from multiple sources that may not be aware of each other.
This is why we have the strangler pattern, right? You wrap the legacy functionality with a set of tests that define the functional requirements of the code, then your new refactored solution needs to keep those tests passing. (And then once you've done that, make sure that your "hacks and bugfixes" get test cases so you can make sure the next refactor accounts for them!)
Re: Ask HN: What is the first thing you implement at a new company?
#127Earlier quoted context omitted.
More likely the hacks are there because requirements changed and the software wasn't initially built to be flexible enough to support change. 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.
In my experience, it's extremely difficult to know which particular lines of code are obsolete. This becomes even more difficult as a codebase ages and is worked on by more contributors. Add on another exponent for every business stakeholder that has a hand in defining the business rules—especially if you have requirements coming from multiple sources that may not be aware of each other.
Which is why comprehensive testing is important. If we have test cases that accurately capture our requirements, then we can refactor and know when we've err'd from the path. If we don't have test cases, then we have to make best guesses (and we know how that one turns out).
Re: Ask HN: What is the first thing you implement at a new company?
#128One 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 is fire and forget word documents in a windows shared drive, does anyone read them? Can I search for the information I need?
Is the department ruled by one or two people who hold all the knowledge? Are all decisions made by those people, or are there people who never read emails and always demand face to face meetings to discuss issues?
Communication is key. What you do and how you do it follows on from how, what, why information is shared.
Re: Ask HN: What is the first thing you implement at a new company?
#129Earlier quoted context omitted.
Pee on their desk. Establish territorial dominance.
Make sure to get a MX Blue mechanical keyboard, so that everyone is aware of who's doing most of the keyboard mashing around the office.
Cherry switches? Millennial... You really need an old IBM, plus it doubles as a weapon if your dominance displays backfire.
Re: Ask HN: What is the first thing you implement at a new company?
#130For 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…
I whole-heartedly agree.
I've worked with too many Senior Engineers who immediately want to change processes in their first two weeks of starting at a new company. It only alienates the other developers.