7 ms·

45. Still coding, probably until I die. Light years ahead of younger developers in the following: * Writing less code * Writing maintainable code * Re-using

45. Still coding, probably until I die. Light years ahead of younger developers in the following: * Writing less code * Writing maintainable code * Re-using existing code (requires reading existing code) * Know how APIs should be written * Knowing how to properly map associations * Know when or when not to use another library * Knowing when to tell a product manager to go back and do some more product managing * Knowing when to say "No" * Knowing how to determine what a stake holder actually needs vs. what they think they want * Understanding that 8 hours today and 8 hours tomorrow is 10x better than 16 hours today. * Saying "I don't know" when asked "How long will it take" or "When will it be done" * Fighting against shitty processes * Fighting FOR processes * Forcing PMs to use software designed for the purpose of creating software instead of accepting requirements through email/slack/invision/zeplin/google docs/tool of someone else's choice

nebari 10y ago
46 - also still coding. I could not agree more! :) Also, knowing why the points in your list are significant and advantageous.
mod 10y ago
> Saying "I don't know" when asked "How long will it take" or "When will it be done" ~5 years experience speaking: How do you do this? I have a very good boss and he knows things, objectively, like "estimates are very squishy," and "developers suck at estimating time" etc. But he still demands time estimates to give clients. Our clients are often agencies, and they get it as well. I do estimates like "10-40 hours, depending on XYZ (things I don't know)" sometimes and it doesn't really raise any eyebrows. That may as well say "I don't know." Are you better than this? Do you just outright refuse or do you have some way you handle it?
- noxToken 10y ago
  The idea behind estimates is to get you to think about the scope the work that is to be done. Quickly walk yourself through the process, give a SWAG, do your best to track your time spent on the task, then review what you got right and wrong in your estimate. It's less about giving the exact time required (in theory - some managers will never understand that) and more about estimating if you have time to complete X, Y and Z.
  - lwlml 10y ago
    SWAG means what in your example?
    - noxToken 10y ago
      Silly Wild Ass Guess
- humanrebar 10y ago
  > How do you do this? Give half-order-of-magnitude estimates as confidence intervals. Avoid using "hours" or "days" as estimates. Story points work really well here. Be extra clear on priorities and burndowns to make it clear that you're not just blowing them off. Give short but frequent demos (not just reports) of progress. If later they're concerned about progress, you can point back to all the times you reviewed the product, touched base about priorities, and agreed on next steps. Make risk really clear to them. If the project is 'get it done in three months or bust', then the payoff (ten times the principal?) better be high enough to account for the risk (30%? 50%? 70%) that you won't make it on time and on budget. That is, you don't want to wait until failure to discover a bad business plan. At the end of the day, you need to be willing to be patient with and/or walk away from 'business people' that can't wrap their heads around the fact that 20% profit on a venture with a 50% failure rate is a bad business plan. Making employees stressed or overworked to compensate is not a humane solution to the problem. To that end, don't work crazy hours to meet a deadline. That is bad for you, bad for your team, and bad for management since it enables dysfunctional planning.
  - ams6110 10y ago
    > Give half-order-of-magnitude estimates My current boss likes to ask "is it a day, a week, a month, or a year" and while sometimes I just want to say "yes, it's one of those" I actually think that's a pretty reasonable way to ask the question.
    - rhizome 9y ago
      I heard a saying once, "Deadlines slip by the units they're measured in." If you say three weeks, it will slip by weeks, not days or months. If the estimate is months, etc.
  - nudded 10y ago
    Could you go more into detail how these story points would work. It seems like in the end a story point would always be associated with a number of days (or hours).
- 6t6t6t6 10y ago
  I have a rule. If I trust the PM, I always give my best estimation and a level of confidence on this estimation with the risks. Like: - I think it will take a week, but this part looks a bit complex, so we may have delays. - Or, I did something similar last month, so I am quite sure that will take 3 days. A good PM will know how to deal with this information and what to expect. If I don't trust the PM, I just add massive paddings.
  - ryandrake 10y ago
    As a PM, of course, I know this padding is happening and generally will add my own: You know in your mind it will take you 3 days You give me, your PM, an estimate of 2 weeks I report up the chain that it will take a month When it's all said and done, you end up getting it done in a month by the skin of your teeth :-)
    - 6t6t6t6 10y ago
      But my point is that if there is a relation of trust between the PM and the developers, padding is unnecessary. I had PMs to who I could give optimistic estimations and risks. That way, the PM could plan the different scenarios (like extra features in case we had spare time). Other PMs, the ones who converted estimations into deadlines, got lots of padding. And the problem of adding padding is that it is time lost, because a developer who adds padding cannot tell that they finished earlier.
- deleted 10y ago
  [deleted]
- Arwill 10y ago
  Often times managers demand an estimate from you, not because they need the job urgently done, but just so that they can hold you accountable to something. If you promise something, they can assume that you will give your best to keep that deadline.
- asmithmd1 10y ago
  Spend time to fully estimate each task in each feature point in hours and double it of course. Now increase the unit of time by one: 3 hours = 6 days, 2 days = 4 weeks, 4 weeks = 8 months.
- memracom 10y ago
  One way to do this is to point out how the requirements are vague, lack context and fail to state how the requirement will benefit the business. Point out how it is sloppiness in documenting requirements that leads to scope creep, cost overruns and ultimately, failure of the business. Tell management that if they really want to give developers responsibility for finding out what is needed then they should fire all the business analysts, project managers and product managers that are not doing their jobs properly. Alternatively, they could accept new processes that make sure requirements are clearly written and include acceptance criteria.
- memracom 10y ago
  One way to do this is to point out how the requirements are vague, lack context and fail to state how the requirement will benefit the business. Point out how it is sloppiness in documenting requirements that leads to scope creep, cost overruns and ultimately, failure of the business. Tell management that if they really want to give developers responsibility for finding out what is needed then they should fire all the business analysts, project managers and product managers that are not doing their jobs properly. Alternatively, they could accept new processes that make sure requirements are clearly written and include acceptance criteria.
- tyingq 10y ago
  In most places "I don't know" doesn't have much effect. Just means the estimate comes from somewhere else. Another developer, or a PM. People are just trying to make decisions about spending money, keeping clients informed, etc. There are some research and moon shot type exceptions. But, for the most part, estimates are a necessary evil.
- cwp 10y ago
  I'll often say something like "I don't know off the top of my head, but if you want I can get back to you with an estimate." Once it's clear that I'm going to spend some non-trivial amount of time working on the estimate, the answer is often, "No, don't bother." On the other hand, if person asking does want me to get back to them, I now have the time to do a good estimate—research the problem, break down the parts of the solution, think about the unknowns. Even a "good" estimate is still squishy, but it does tend to be based on explicit assumptions, and often flushes out hidden design or spec issues.
- defined 10y ago
  > How do you do this? I draw them the Cone of Uncertainty (http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/ http://www.construx.com/Thought_Leadership/Books/The_Cone_of...).
cyrux004 10y ago
can you justify the 3-5x difference in annual compensation that younger developer makes can you justify the 2-3x difference between you and a guy who was been coding for 5-7 years ?
- pg314 10y ago
  Yes and yes. If I compare myself against when I just started, I'm easily 10x more valuable now (in some cases 100x). And I would still choose my current self over 5 copies of myself at 5-7 years of experience. Maybe if you have a simple problem, like a CRUD application or a simple website, it wouldn't matter much. But for harder problems there is no contest.
  - Clubber 10y ago
    This. Most development is CRUD and is trivial. Write a DSS and/or automation system that is bulletproof and saves millions and it's significantly more difficult. The difference between using something like Biztalk and writing something like Biztalk is orders of magnitude more difficult. If you are using someone else's framework for the majority of what your application does, that's not really software development. I know many people won't like hearing that.
- deleted 10y ago
  [deleted]
- rimliu 10y ago
  Wait a minute, are those multipliers real?
- svachalek 10y ago
  3-5X? What country is this? Typically in Silicon Valley there's a rapid rise in the first 5-7 years and then it gets pretty flat (say, 1.1X or 1.2X not 2-3X) unless you're actually taking on a bigger role (and thus getting paid for those responsibilities rather than "experience" per se). When you look at it from a company cost perspective, the ratios get even smaller. The fixed costs (desk, power, healthcare, etc) are pretty much the same no matter the experience level of the engineer.
andrey_utkin 10y ago
> Forcing PMs to use software designed for the purpose of creating software instead of accepting requirements through email/slack/invision/zeplin/google docs/tool of someone else's choice Could you please specify examples of proper software for this purpose (communicating product/feature requirements is meant here I suppose)? Do you mean reqs must go through the issue tracker or official original spec document?
- Mc_Big_G 10y ago
  I'm referring to using a ticket system like Jira/Assembla/Pivotal Tracker/Trello etc...
  - taway_1212 10y ago
    Lol for a second I thought you meant something like Rational RequisitePro...
solox3 10y ago
Junior here. What does "map associations" mean in this context?
- Mc_Big_G 10y ago
  I was referring to the best way to model associations on client/server code and how that maps to the database schema. For some reason, I find that younger devs want to invent a new way to do relationships every time they have to implement a new one.
shamaku 10y ago
Nice. You should definitely write an article.
pjmlp 10y ago
On my 40's, a bit younger than you, I agree with every point.
ishbits 10y ago
One thing I do way less in my 40s is over engineer a solution, or worry about all possible someday maybe use cases of a class many Java developers seem to like to design for.
psyc 10y ago
I feel similarly as far as being on a whole other level now. I'm 40 and semi-retired. I spend far more time coding per day than I did at the peak of my career in the industry. And compared to myself back then... I don't even know how to make the comparison. The concepts and systems I play with every day now wouldn't have been anywhere in sight for me then.

nebari 10y ago

46 - also still coding. I could not agree more! :) Also, knowing why the points in your list are significant and advantageous.

mod 10y ago

> Saying "I don't know" when asked "How long will it take" or "When will it be done" ~5 years experience speaking: How do you do this? I have a very good boss and he knows things, objectively, like "estimates are very squishy," and "developers suck at estimating time" etc. But he still demands time estimates to give clients. Our clients are often agencies, and they get it as well. I do estimates like "10-40 hours, depending on XYZ (things I don't know)" sometimes and it doesn't really raise any eyebrows. That may as well say "I don't know." Are you better than this? Do you just outright refuse or do you have some way you handle it?

noxToken 10y ago
The idea behind estimates is to get you to think about the scope the work that is to be done. Quickly walk yourself through the process, give a SWAG, do your best to track your time spent on the task, then review what you got right and wrong in your estimate. It's less about giving the exact time required (in theory - some managers will never understand that) and more about estimating if you have time to complete X, Y and Z.
- lwlml 10y ago
  SWAG means what in your example?
  - noxToken 10y ago
    Silly Wild Ass Guess
humanrebar 10y ago
> How do you do this? Give half-order-of-magnitude estimates as confidence intervals. Avoid using "hours" or "days" as estimates. Story points work really well here. Be extra clear on priorities and burndowns to make it clear that you're not just blowing them off. Give short but frequent demos (not just reports) of progress. If later they're concerned about progress, you can point back to all the times you reviewed the product, touched base about priorities, and agreed on next steps. Make risk really clear to them. If the project is 'get it done in three months or bust', then the payoff (ten times the principal?) better be high enough to account for the risk (30%? 50%? 70%) that you won't make it on time and on budget. That is, you don't want to wait until failure to discover a bad business plan. At the end of the day, you need to be willing to be patient with and/or walk away from 'business people' that can't wrap their heads around the fact that 20% profit on a venture with a 50% failure rate is a bad business plan. Making employees stressed or overworked to compensate is not a humane solution to the problem. To that end, don't work crazy hours to meet a deadline. That is bad for you, bad for your team, and bad for management since it enables dysfunctional planning.
- ams6110 10y ago
  > Give half-order-of-magnitude estimates My current boss likes to ask "is it a day, a week, a month, or a year" and while sometimes I just want to say "yes, it's one of those" I actually think that's a pretty reasonable way to ask the question.
  - rhizome 9y ago
    I heard a saying once, "Deadlines slip by the units they're measured in." If you say three weeks, it will slip by weeks, not days or months. If the estimate is months, etc.
- nudded 10y ago
  Could you go more into detail how these story points would work. It seems like in the end a story point would always be associated with a number of days (or hours).
6t6t6t6 10y ago
I have a rule. If I trust the PM, I always give my best estimation and a level of confidence on this estimation with the risks. Like: - I think it will take a week, but this part looks a bit complex, so we may have delays. - Or, I did something similar last month, so I am quite sure that will take 3 days. A good PM will know how to deal with this information and what to expect. If I don't trust the PM, I just add massive paddings.
- ryandrake 10y ago
  As a PM, of course, I know this padding is happening and generally will add my own: You know in your mind it will take you 3 days You give me, your PM, an estimate of 2 weeks I report up the chain that it will take a month When it's all said and done, you end up getting it done in a month by the skin of your teeth :-)
  - 6t6t6t6 10y ago
    But my point is that if there is a relation of trust between the PM and the developers, padding is unnecessary. I had PMs to who I could give optimistic estimations and risks. That way, the PM could plan the different scenarios (like extra features in case we had spare time). Other PMs, the ones who converted estimations into deadlines, got lots of padding. And the problem of adding padding is that it is time lost, because a developer who adds padding cannot tell that they finished earlier.
deleted 10y ago
[deleted]
Arwill 10y ago
Often times managers demand an estimate from you, not because they need the job urgently done, but just so that they can hold you accountable to something. If you promise something, they can assume that you will give your best to keep that deadline.
asmithmd1 10y ago
Spend time to fully estimate each task in each feature point in hours and double it of course. Now increase the unit of time by one: 3 hours = 6 days, 2 days = 4 weeks, 4 weeks = 8 months.
memracom 10y ago
One way to do this is to point out how the requirements are vague, lack context and fail to state how the requirement will benefit the business. Point out how it is sloppiness in documenting requirements that leads to scope creep, cost overruns and ultimately, failure of the business. Tell management that if they really want to give developers responsibility for finding out what is needed then they should fire all the business analysts, project managers and product managers that are not doing their jobs properly. Alternatively, they could accept new processes that make sure requirements are clearly written and include acceptance criteria.
memracom 10y ago
One way to do this is to point out how the requirements are vague, lack context and fail to state how the requirement will benefit the business. Point out how it is sloppiness in documenting requirements that leads to scope creep, cost overruns and ultimately, failure of the business. Tell management that if they really want to give developers responsibility for finding out what is needed then they should fire all the business analysts, project managers and product managers that are not doing their jobs properly. Alternatively, they could accept new processes that make sure requirements are clearly written and include acceptance criteria.
tyingq 10y ago
In most places "I don't know" doesn't have much effect. Just means the estimate comes from somewhere else. Another developer, or a PM. People are just trying to make decisions about spending money, keeping clients informed, etc. There are some research and moon shot type exceptions. But, for the most part, estimates are a necessary evil.
cwp 10y ago
I'll often say something like "I don't know off the top of my head, but if you want I can get back to you with an estimate." Once it's clear that I'm going to spend some non-trivial amount of time working on the estimate, the answer is often, "No, don't bother." On the other hand, if person asking does want me to get back to them, I now have the time to do a good estimate—research the problem, break down the parts of the solution, think about the unknowns. Even a "good" estimate is still squishy, but it does tend to be based on explicit assumptions, and often flushes out hidden design or spec issues.
defined 10y ago
> How do you do this? I draw them the Cone of Uncertainty (http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/ http://www.construx.com/Thought_Leadership/Books/The_Cone_of...).

cyrux004 10y ago

can you justify the 3-5x difference in annual compensation that younger developer makes can you justify the 2-3x difference between you and a guy who was been coding for 5-7 years ?

pg314 10y ago
Yes and yes. If I compare myself against when I just started, I'm easily 10x more valuable now (in some cases 100x). And I would still choose my current self over 5 copies of myself at 5-7 years of experience. Maybe if you have a simple problem, like a CRUD application or a simple website, it wouldn't matter much. But for harder problems there is no contest.
- Clubber 10y ago
  This. Most development is CRUD and is trivial. Write a DSS and/or automation system that is bulletproof and saves millions and it's significantly more difficult. The difference between using something like Biztalk and writing something like Biztalk is orders of magnitude more difficult. If you are using someone else's framework for the majority of what your application does, that's not really software development. I know many people won't like hearing that.
deleted 10y ago
[deleted]
rimliu 10y ago
Wait a minute, are those multipliers real?
svachalek 10y ago
3-5X? What country is this? Typically in Silicon Valley there's a rapid rise in the first 5-7 years and then it gets pretty flat (say, 1.1X or 1.2X not 2-3X) unless you're actually taking on a bigger role (and thus getting paid for those responsibilities rather than "experience" per se). When you look at it from a company cost perspective, the ratios get even smaller. The fixed costs (desk, power, healthcare, etc) are pretty much the same no matter the experience level of the engineer.

andrey_utkin 10y ago

> Forcing PMs to use software designed for the purpose of creating software instead of accepting requirements through email/slack/invision/zeplin/google docs/tool of someone else's choice Could you please specify examples of proper software for this purpose (communicating product/feature requirements is meant here I suppose)? Do you mean reqs must go through the issue tracker or official original spec document?

Mc_Big_G 10y ago
I'm referring to using a ticket system like Jira/Assembla/Pivotal Tracker/Trello etc...
- taway_1212 10y ago
  Lol for a second I thought you meant something like Rational RequisitePro...

solox3 10y ago

Junior here. What does "map associations" mean in this context?

Mc_Big_G 10y ago
I was referring to the best way to model associations on client/server code and how that maps to the database schema. For some reason, I find that younger devs want to invent a new way to do relationships every time they have to implement a new one.

shamaku 10y ago

Nice. You should definitely write an article.

pjmlp 10y ago

On my 40's, a bit younger than you, I agree with every point.

ishbits 10y ago

One thing I do way less in my 40s is over engineer a solution, or worry about all possible someday maybe use cases of a class many Java developers seem to like to design for.

psyc 10y ago

I feel similarly as far as being on a whole other level now. I'm 40 and semi-retired. I spend far more time coding per day than I did at the peak of my career in the industry. And compared to myself back then... I don't even know how to make the comparison. The concepts and systems I play with every day now wouldn't have been anywhere in sight for me then.