3 ms·
I think you're being too dismissive of the value of setting expectations about how work is done. I'll try to make it relatable for software folks... I've deve
by VikingCoder 8y ago
I think you're being too dismissive of the value of setting expectations about how work is done. I'll try to make it relatable for software folks...
I've developed software in places where we:
* had coding style guides
* promoted many compiler Warnings to Errors
* worked off of Bug and Feature lists, not just going off coding
* had to document all changes (for the FDA) in a certain way
* were expected to keep Continuous Integration tests running
* were expected to write unit tests as much as possible, and have very high code coverage
* attempted to do Test-Driven Development for most work (because it was the best way to make sure our code was testable [see "Working Effectively With Legacy Code" by Michael C. Feathers for inspiration)
* had a strict process for handling customer feedback, to ensure we triaged it appropriately
* had to lock our workstations when we stepped away (Sarbanes–Oxley)
* had a code review process for submitting changes
* had a design review process for larger changes (especially including adopting new tools)
* used a very restricted set of programming languages for any new work, even for small tools and one-offs
* followed SCRUM (daily stand-ups, story points, etc.)
* used Objectives and Key Results to plan our work
* had a process to discuss changing any of these
* all used one tool to manage our calendar (even for personal time blocks that didn't impact anyone else)
* all used one messaging tool
Every single one of those is an example of being told how to do my work. And they all existed to set expectations about how I was supposed to interact with my teammates. Whose responsibility was it to do things, how do we keep track of the things, how do we make decisions, how do we stay out of each others' way, how do we avoid unnecessary interruptions.
I've heard someone express the phrase, "We don't do that here." What was meant by it is, don't get dragged down into a discussion about whether something is right or wrong. We have a culture. There are rules. We follow them. (And there's the door, if you don't like it.)
- noir_lord 8y agoTo be honest everything on that list sounds good to me as each was decently implemented. At that level you are much more engineering than throwing stuff over the wall and running away. I wish the system I inherited was structured that way!. I got the code. No comments, no tests, no test environment, no documentation, no history and the code is hilarious. At that point your job is archaeology not engineering.