4 ms·

That’s true! But the clusterfuck is a necessary part of the product birthing process, not something to be scorned. The baby product now needs to be nurtured and

That’s true! But the clusterfuck is a necessary part of the product birthing process, not something to be scorned. The baby product now needs to be nurtured and educated into a functioning adult. There are plenty of opportunities here. And this is where branding yourself comes in, to get the political power you need to do something right and fun with the product. Instead of a maintenance programmer, call yourself a “scalability engineer.” If you’re in a regulatory heavy business, read the regulatory manuals and become a “compliance engineer.” It will be super helpful for your career and give you the clout you need to make the necessary product improvements as the business matures. Just my two cents. I think you’re being downvoted because your tone comes across as scornful, but it’s really a fantastic opportunity for back end devs to make a difference.

cjfd 7y ago
I don't think the clusterf*ck is necessary for anything. It is an indication of immature people working on something when a product goes through a phase like that. Of course, at the stage where the project is 100 lines large one does not need much structure but it can be added gradually without a noticable disruption in the flow of features supported. The whole 'scalability engineer' and 'compliance engineer' title mumbo jumbo sounds very phoney to me. As far as the compliance part is concerned I feel inclined to make up some fake dictionary definition for it in the style of the devils dictionary for maximum cynicism. Compliance: a lot of paperwork that asserts that a set of desirable attributes apply to the mirage that management has dreamt up about a project. The mirage may or may not be in any way related to the actual state of said project.
- drunkpotato 7y ago
  That’s a fair and reasonable perspective. I’m curious if you’ve worked on such a product that had a baked-in level of maturity from the start? I never have. I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck! Scalability engineer and compliance engineer very much are phony mumbo jumbo from the perspective of a software engineer. However from the business perspective they are very real and I think they are helpful to communicate one’s own level of maturity and ability for the business owners to trust you to get things done for them. It’s about communication and signaling more than the reality of what you do.
  - cjfd 7y ago
    I have seen the startup stages of software projects with varying levels of quality. The whole spectrum from very bad to very good can be observed and/or participated in in the wild. The good ones start out with one experienced developer. After two or three features have been added (within two weeks to a month) more developers, possibly less experienced ones can be added. Their number should grow somewhat slowly mainly to make sure that they are not getting in each others way too much. Practices that make this work are automated testing and code review. Occasionally, some pair programming can be practiced, especially when some refactoring is needed. I am talking about limited refactoring here, maybe taking two to three days. If the project can be split in a front end and a back end one may start out with two developers. In theory a system that consists of N services might start with N developers but if N starts out larger than 3 one is quite likely engaging in over engineering.
  - PaulStatezny 7y ago
    I agree with cjfd; it's a false dichotomy. "Either we put zero effort into making this code maintainable, or we won't move fast enough." > I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck! I'm personally working on a v1, and (you'll have to take my word for it) it is far from that. We are making conscious decisions: "here's a guess about the future that we're confident about, so we're willing to add in more structure/abstraction here," or, "We're not sure about the future of this feature set; let's be clean but minimal about it." Also, co-workers have raved about our work on this project, including speed. So that's further evidence that it's a false dichotomy.
- mwcampbell 7y ago
  Your cynicism about compliance is misplaced IMO. Compliance is about making sure the product covers things that are boring but important, like security, privacy, and accessibility. These are things that the pioneers blithely ignore so they can ship something. But if they continue to be ignored, there are real, sometimes disastrous, consequences (even if the disaster is just for one person, e.g. an otherwise well-qualified blind person losing their job because an app they're required to use is inaccessible).

cjfd 7y ago

I don't think the clusterf*ck is necessary for anything. It is an indication of immature people working on something when a product goes through a phase like that. Of course, at the stage where the project is 100 lines large one does not need much structure but it can be added gradually without a noticable disruption in the flow of features supported. The whole 'scalability engineer' and 'compliance engineer' title mumbo jumbo sounds very phoney to me. As far as the compliance part is concerned I feel inclined to make up some fake dictionary definition for it in the style of the devils dictionary for maximum cynicism. Compliance: a lot of paperwork that asserts that a set of desirable attributes apply to the mirage that management has dreamt up about a project. The mirage may or may not be in any way related to the actual state of said project.

drunkpotato 7y ago
That’s a fair and reasonable perspective. I’m curious if you’ve worked on such a product that had a baked-in level of maturity from the start? I never have. I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck! Scalability engineer and compliance engineer very much are phony mumbo jumbo from the perspective of a software engineer. However from the business perspective they are very real and I think they are helpful to communicate one’s own level of maturity and ability for the business owners to trust you to get things done for them. It’s about communication and signaling more than the reality of what you do.
- cjfd 7y ago
  I have seen the startup stages of software projects with varying levels of quality. The whole spectrum from very bad to very good can be observed and/or participated in in the wild. The good ones start out with one experienced developer. After two or three features have been added (within two weeks to a month) more developers, possibly less experienced ones can be added. Their number should grow somewhat slowly mainly to make sure that they are not getting in each others way too much. Practices that make this work are automated testing and code review. Occasionally, some pair programming can be practiced, especially when some refactoring is needed. I am talking about limited refactoring here, maybe taking two to three days. If the project can be split in a front end and a back end one may start out with two developers. In theory a system that consists of N services might start with N developers but if N starts out larger than 3 one is quite likely engaging in over engineering.
- PaulStatezny 7y ago
  I agree with cjfd; it's a false dichotomy. "Either we put zero effort into making this code maintainable, or we won't move fast enough." > I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck! I'm personally working on a v1, and (you'll have to take my word for it) it is far from that. We are making conscious decisions: "here's a guess about the future that we're confident about, so we're willing to add in more structure/abstraction here," or, "We're not sure about the future of this feature set; let's be clean but minimal about it." Also, co-workers have raved about our work on this project, including speed. So that's further evidence that it's a false dichotomy.
mwcampbell 7y ago
Your cynicism about compliance is misplaced IMO. Compliance is about making sure the product covers things that are boring but important, like security, privacy, and accessibility. These are things that the pioneers blithely ignore so they can ship something. But if they continue to be ignored, there are real, sometimes disastrous, consequences (even if the disaster is just for one person, e.g. an otherwise well-qualified blind person losing their job because an app they're required to use is inaccessible).