4 ms·

Hopping or starting a company to sell your work are becoming the fastest ways to get "promoted."

kradroy 8y ago
I was going to suggest this from my experience. I hate to burst GP's bubble, but the attitude and environment at his next job probably won't be any better in regard to "best practices." It's extremely difficult to gauge how your attitude toward development compares with a prospective team's after an hour of chatting. I became a manager last year and quickly discovered that changing others' behavior and habits is next to impossible. And if he does happen to find a new team that matches his work ethic he can be certain that 1 or 2 years down the line it won't any longer. I think the only two ways to avoid this is to become a contractor and switch gigs every 2 years, or start your own company and hope the people you hire share your attitude.
- hobs 8y ago
  Unfortunately yes, though another path is making a lot of friends so that you can network for the decent jobs, temporary though they might be.
- hinkley 8y ago
  I've had very good luck changing the behavior of junior developers and moderate luck changing the behavior of mid level developers that are hungry for a promotion. I can count on my fingers (couldn't say if that's one hand or two) how many senior devs I've gotten to come around. If you're interested in progress and growth, I can say with a high degree of certainty that what you don't want to do is apply to work on a very stable team. These people are always confident that they know what they're doing - even when they agree that the outcomes aren't great. They've had lots of time to practice their rationalizations and that kind of cognitive dissonance can be pretty jarring/aggravating. By definition, starting your own company or contracting will avoid that situation, but you don't need to take your ball and go home just to get the right kind of environment.
  - pvarangot 8y ago
    I had senior people change habits and practices but at the expense of huge failures or years of leading by example. The patience and the effort are humongous and almost ridiculous when you compare them to how quarterly or even bi-quarterly planing cycles look.
    - hinkley 8y ago
      Early in my career, the concept that someone might know of a showstopping problem and chose to do nothing left me appalled and feeling rather betrayed. Fifteen years later I sit in meetings telling people (some of them still older than me) not to touch the stove because it will hurt, and I have to patiently wait until someone gets hurt before we can discuss the proverbial oven mitts. The problem with doing something right the first time is nobody appreciates how hard it was.
      - deleted 8y ago
        [deleted]
      - drawkbox 8y ago
        > The problem with doing something right the first time is nobody appreciates how hard it was. Sometimes if you do put in quality and do it right in development it costs you in time and then by perception. When you hit the ship date over finishing the iteration/version/product you have problems after ship from external customers, when you do it right and handle the problem in development before ship, you take a hit in perception internally. The problems after ship can harm a product/company more than a slight delay in shipping, but today it seems people don't care as much as there is more specialization and larger teams where it is 'not my problem'. Some clients/project managers see a bad product shipped on time as good, and a good product shipped late as always bad. The external perception should play more into that perception not just hitting their part of the project goals/milestones. Hitting dates is hugely important, but messing up a product with the customer can be deeply problematic. Noone truly remembers a late product after it ships and is quality, creative and functional, they remember a bad product. I prefer the Valve Time [1] philosophy, get the product right over the date, and don't set dates until you have the product actually ready. [1] https://developer.valvesoftware.com/wiki/Valve_Time https://developer.valvesoftware.com/wiki/Valve_Time
- pmiller2 8y ago
  Why would one need to become a contractor to switch gigs every 2 years? Seems like that’s the new normal with employers not wanting to invest in employees anymore.
- josephjrobison 8y ago
  As a non-developer, how can I hire someone (or a team) like OP that focuses on automating menial stuff and focuses on the most important? Does a development agency that focuses on this model exist? Of course they should be paid more per hour (or other unit) than your average, less optimized agency, but the sum total should be less than hiring inefficient agencies. (P.S. I understand the best developers probably don't want to start or work at development agencies, but assuming there are some.)
  - honopu 8y ago
    I’d hope they all do. If you get an experienced developer they should want to automate all of this. My former boss took the model of improving processes and revenue, then taking a cut of the difference ongoing. He had financial freedom already, so this was the best use of his time. With some companies you aren’t given all of the information to make the right decision for efficiencies sake, or they write such a rigid spec there’s no room for improvement. Personally I love spending the time where I can see it saving so much time for the end. You might not need an agency, you might just need a developer to help write what you want to create and work a spec that you can give to an uncreative team/agency to create. Agencies make a decent amount on the discovery phase, so you’d be cutting that out. At that point you could go directly to someone that could implement it.
    - josephjrobison 8y ago
      That's a great idea, will definitely try this out. Seems to be a good idea to separate out the architecting from the actual implementation. Makes sense, because if someone knows they'll have to be implementing, it could cloud their plan for the ideal solution. Similar to separating out design, UX, and development roles.
  - bradknowles 8y ago
    Body shops don't work like this. Their purpose is to put butts in seats, regardless of whether or not that butt is attached to anything else that is functional. Functioning in this manner would actually be counter-productive for them, because it would reduce the number of butts that they have to put into seats, and would reduce the number of seats into which they could put butts. If you know of a development agency, odds are that it is probably a body shop. The places that do work like this are more like Unicorns. And Unicorns are damned hard to find and hire -- or get hired by them.

I was going to suggest this from my experience. I hate to burst GP's bubble, but the attitude and environment at his next job probably won't be any better in regard to "best practices." It's extremely difficult to gauge how your attitude toward development compares with a prospective team's after an hour of chatting. I became a manager last year and quickly discovered that changing others' behavior and habits is next to impossible. And if he does happen to find a new team that matches his work ethic he can be certain that 1 or 2 years down the line it won't any longer. I think the only two ways to avoid this is to become a contractor and switch gigs every 2 years, or start your own company and hope the people you hire share your attitude.

hobs 8y ago
Unfortunately yes, though another path is making a lot of friends so that you can network for the decent jobs, temporary though they might be.
hinkley 8y ago
I've had very good luck changing the behavior of junior developers and moderate luck changing the behavior of mid level developers that are hungry for a promotion. I can count on my fingers (couldn't say if that's one hand or two) how many senior devs I've gotten to come around. If you're interested in progress and growth, I can say with a high degree of certainty that what you don't want to do is apply to work on a very stable team. These people are always confident that they know what they're doing - even when they agree that the outcomes aren't great. They've had lots of time to practice their rationalizations and that kind of cognitive dissonance can be pretty jarring/aggravating. By definition, starting your own company or contracting will avoid that situation, but you don't need to take your ball and go home just to get the right kind of environment.
- pvarangot 8y ago
  I had senior people change habits and practices but at the expense of huge failures or years of leading by example. The patience and the effort are humongous and almost ridiculous when you compare them to how quarterly or even bi-quarterly planing cycles look.
  - hinkley 8y ago
    Early in my career, the concept that someone might know of a showstopping problem and chose to do nothing left me appalled and feeling rather betrayed. Fifteen years later I sit in meetings telling people (some of them still older than me) not to touch the stove because it will hurt, and I have to patiently wait until someone gets hurt before we can discuss the proverbial oven mitts. The problem with doing something right the first time is nobody appreciates how hard it was.
    - deleted 8y ago
      [deleted]
    - drawkbox 8y ago
      > The problem with doing something right the first time is nobody appreciates how hard it was. Sometimes if you do put in quality and do it right in development it costs you in time and then by perception. When you hit the ship date over finishing the iteration/version/product you have problems after ship from external customers, when you do it right and handle the problem in development before ship, you take a hit in perception internally. The problems after ship can harm a product/company more than a slight delay in shipping, but today it seems people don't care as much as there is more specialization and larger teams where it is 'not my problem'. Some clients/project managers see a bad product shipped on time as good, and a good product shipped late as always bad. The external perception should play more into that perception not just hitting their part of the project goals/milestones. Hitting dates is hugely important, but messing up a product with the customer can be deeply problematic. Noone truly remembers a late product after it ships and is quality, creative and functional, they remember a bad product. I prefer the Valve Time [1] philosophy, get the product right over the date, and don't set dates until you have the product actually ready. [1] https://developer.valvesoftware.com/wiki/Valve_Time https://developer.valvesoftware.com/wiki/Valve_Time
pmiller2 8y ago
Why would one need to become a contractor to switch gigs every 2 years? Seems like that’s the new normal with employers not wanting to invest in employees anymore.
josephjrobison 8y ago
As a non-developer, how can I hire someone (or a team) like OP that focuses on automating menial stuff and focuses on the most important? Does a development agency that focuses on this model exist? Of course they should be paid more per hour (or other unit) than your average, less optimized agency, but the sum total should be less than hiring inefficient agencies. (P.S. I understand the best developers probably don't want to start or work at development agencies, but assuming there are some.)
- honopu 8y ago
  I’d hope they all do. If you get an experienced developer they should want to automate all of this. My former boss took the model of improving processes and revenue, then taking a cut of the difference ongoing. He had financial freedom already, so this was the best use of his time. With some companies you aren’t given all of the information to make the right decision for efficiencies sake, or they write such a rigid spec there’s no room for improvement. Personally I love spending the time where I can see it saving so much time for the end. You might not need an agency, you might just need a developer to help write what you want to create and work a spec that you can give to an uncreative team/agency to create. Agencies make a decent amount on the discovery phase, so you’d be cutting that out. At that point you could go directly to someone that could implement it.
  - josephjrobison 8y ago
    That's a great idea, will definitely try this out. Seems to be a good idea to separate out the architecting from the actual implementation. Makes sense, because if someone knows they'll have to be implementing, it could cloud their plan for the ideal solution. Similar to separating out design, UX, and development roles.
- bradknowles 8y ago
  Body shops don't work like this. Their purpose is to put butts in seats, regardless of whether or not that butt is attached to anything else that is functional. Functioning in this manner would actually be counter-productive for them, because it would reduce the number of butts that they have to put into seats, and would reduce the number of seats into which they could put butts. If you know of a development agency, odds are that it is probably a body shop. The places that do work like this are more like Unicorns. And Unicorns are damned hard to find and hire -- or get hired by them.