221–230 of 293 posts
Earlier 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 just arrived at a company why are you pushing to change anything. They obviously already have a working process and you should be careful to change anything that works, especially when you may not yet know all of the more hidden details.
It depends on why you're brought in to the company. Especially in management it's not uncommon to hire people with the explicit notion that they don't have a satisfactory working process, it needs significant changes to achieve the desired results, and the new hire would be expected to start fixing the current process almost immediately.
For 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…
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...
That is I more or less demand source control, work on automated builds/tests (on each commit, not daily), start to log everything I see in JIRA (or another tracker), Look for an up to date schedule (ie, discern business priorities and timelines), attempt to start specifying how future things ought to work, train my coworkers to see when I'm wearing earplugs to drown out their non work related chatter....
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
For 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…
This honestly took me a while to learn - it's so easy to jump in and be a smartass (and I've been guilty of this before) about how bad things are, but a) suggesting small, incremental changes that demonstrate a nuanced understanding of where things went wrong and b) volunteering to work on making things better goes a long way. Most of the team will already often know and agree on what is bad - but just won't be empow…
Yeah same here. I think I pissed off my manager pretty quickly at my current job by trying to change how they did certain things before getting an understanding of why they did them that way, but I realized my mistake and went into more of an observer-mindset for awhile.
Over time I built up a reputation with reducing friction in smaller ways on specific features I worked on, and then applied that same thinking to larger scale issues I saw. They were much more receptive once they knew I could make valuable contributions, and now I'm one of the main people establishing patterns and architecture decisions at my company.
Learning to establish myself for awhile before making process changes was a great learning experience that I plan to take with me to all future roles.
For 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 was asked in an interview "What is the first thing you will change?" (I was interviewing for a Manager position, but I think this applies no matter the position you are being interviewed for.) My response was - "I don't know. I need to spend time getting to know the team, understand our product, and better understand priorities." I try to use this question in interviews with senior people, be they Developers or Man…
My response: "My mind" ... As i seek to _first_ understand and then to act...
A Docker or Vagrant setup to match their prod as closely as possible, for local dev purposes. It boggles my mind how many developers _still_ install PHP/MySQL/Ruby/Node/etc on their daily desktop and are surprised when something doesn't work as expected on production.
Do you typically choose one over the other?
I doubt I use either of them correctly. But I do love the way I use them.
Earlier quoted context omitted.
I was asked in an interview "What is the first thing you will change?" (I was interviewing for a Manager position, but I think this applies no matter the position you are being interviewed for.) My response was - "I don't know. I need to spend time getting to know the team, understand our product, and better understand priorities." I try to use this question in interviews with senior people, be they Developers or Man…
> "What is the first thing you will change?" My response: "My mind" ... As i seek to _first_ understand and then to act...