5 ms·

My company has been getting a lot of talent from Amazon and Microsoft, so we are getting their "scar tissue" without any of the context, jacking up our culture.

My company has been getting a lot of talent from Amazon and Microsoft, so we are getting their "scar tissue" without any of the context, jacking up our culture. I have to do a detailed doc and plan for everything. It wouldn't be a big deal but we've gone from 700 to 1500 employees in just 2 years, so its been fast change.

xemdetia 9y ago
I find it almost required to try and jolt these people out of it if they move between organizations. There is definitely a value to procedure but it often comes up that the underlying assumptions have moved as well. You have to encourage people to reevaluate eventually or the third or four generation handling the bureaucracy does not understand the why and does the same thing covered by the first procedure on some grand new thing that looks about the same.
- louithethrid 9y ago
  If you have a floorplan, and get to draft a process, you can use that to draw turtlegraphics with emails.
DonbunEf7 9y ago
I just left a place where nobody writes design documentation. I requested that several teams write documentation for their tasks and they refused. As your company grows from small-sized to medium-sized, your technical processes need to grow, too.
- devmunchies 9y ago
  I agree with documentation, but detailed "plans" are different. Its a doc about what my product/feature/quarter/sprint will entail and almost never matches up to reality because things change. Documentation, on the other hand, it written after or during the code and has nothing to do with planning.
sidlls 9y ago
> I have to do a detailed doc and plan for everything. I find spending a few days writing a detailed, in-depth design document for a given implementation often saves weeks or more of development. In the immediate term it takes longer. In the medium to longer term a thorough design can often lead to fewer bugs, less severe bugs, and less complicated enhancement development. What you describe is what engineering is, at least partly. Your attitude, which is quite common, is why I scoff at calling what this industry does "software engineering". It's rarely as thoughtful, careful and detailed as engineering requires. Not that that is a bad thing. Often what a business in this industry is making just isn't complicated enough to need much beyond simplistic hacking at a terminal.
- panic 9y ago
  I don't think this is an argument for requiring plans, though: you can always encourage them, but in the end it should be up to the person doing the design. Otherwise you end up with the absurdity of having to write a detailed plan and wait a month for approval just to change the positioning of a button slightly.
  - sidlls 9y ago
    If the implementation outlives the implementer it most certainly shouldn't be up to him whether he does the design or not.
    - panic 9y ago
      What I'm saying is that depends on the nature of the code that's being written. Many small improvements can be made with a simple code change that has clear meaning on its own -- a long approval process would just make these changes less likely to happen.
      - sidlls 9y ago
        The point of having an approval process of any length or complexity is precisely to make changes less likely to happen ad hoc. That's a Good Thing (tm)! Sometimes "small improvements" have ramifications outside of the context of the change (potentially significant ones). The person implementing these improvements has to understand the scope of the change (including side effects on external systems, if any), and that effort should be documented somewhere or at the very least reviewed by peers for correctness, especially for truly mission-critical or sensitive systems. It doesn't have to be a "fill out these forms in triplicate and don't forget the new cover on your TPS report mmmkay" kind of documented effort: it's not one extreme or another.

xemdetia 9y ago

I find it almost required to try and jolt these people out of it if they move between organizations. There is definitely a value to procedure but it often comes up that the underlying assumptions have moved as well. You have to encourage people to reevaluate eventually or the third or four generation handling the bureaucracy does not understand the why and does the same thing covered by the first procedure on some grand new thing that looks about the same.

louithethrid 9y ago
If you have a floorplan, and get to draft a process, you can use that to draw turtlegraphics with emails.

DonbunEf7 9y ago

I just left a place where nobody writes design documentation. I requested that several teams write documentation for their tasks and they refused. As your company grows from small-sized to medium-sized, your technical processes need to grow, too.

devmunchies 9y ago
I agree with documentation, but detailed "plans" are different. Its a doc about what my product/feature/quarter/sprint will entail and almost never matches up to reality because things change. Documentation, on the other hand, it written after or during the code and has nothing to do with planning.

sidlls 9y ago

> I have to do a detailed doc and plan for everything. I find spending a few days writing a detailed, in-depth design document for a given implementation often saves weeks or more of development. In the immediate term it takes longer. In the medium to longer term a thorough design can often lead to fewer bugs, less severe bugs, and less complicated enhancement development. What you describe is what engineering is, at least partly. Your attitude, which is quite common, is why I scoff at calling what this industry does "software engineering". It's rarely as thoughtful, careful and detailed as engineering requires. Not that that is a bad thing. Often what a business in this industry is making just isn't complicated enough to need much beyond simplistic hacking at a terminal.

panic 9y ago
I don't think this is an argument for requiring plans, though: you can always encourage them, but in the end it should be up to the person doing the design. Otherwise you end up with the absurdity of having to write a detailed plan and wait a month for approval just to change the positioning of a button slightly.
- sidlls 9y ago
  If the implementation outlives the implementer it most certainly shouldn't be up to him whether he does the design or not.
  - panic 9y ago
    What I'm saying is that depends on the nature of the code that's being written. Many small improvements can be made with a simple code change that has clear meaning on its own -- a long approval process would just make these changes less likely to happen.
    - sidlls 9y ago
      The point of having an approval process of any length or complexity is precisely to make changes less likely to happen ad hoc. That's a Good Thing (tm)! Sometimes "small improvements" have ramifications outside of the context of the change (potentially significant ones). The person implementing these improvements has to understand the scope of the change (including side effects on external systems, if any), and that effort should be documented somewhere or at the very least reviewed by peers for correctness, especially for truly mission-critical or sensitive systems. It doesn't have to be a "fill out these forms in triplicate and don't forget the new cover on your TPS report mmmkay" kind of documented effort: it's not one extreme or another.