942 reputation
610
bio website
location
age
visits member for 4 years, 2 months
seen Aug 29 at 18:47

Oct
15
awarded  Yearling
Oct
15
awarded  Yearling
Feb
12
awarded  Guru
Jan
10
awarded  Nice Answer
Oct
15
awarded  Yearling
Sep
26
revised How do you explain refactoring to a non-technical person?
added 180 characters in body
Sep
26
comment How do you explain refactoring to a non-technical person?
@KirkBroadhurst This post explains it slightly differently. You make the decision to take on technical debt strategically. If you explain it this way, you won't get that question.
Sep
26
comment How do you explain refactoring to a non-technical person?
@ThomasEding (1) This is not an explanation of refactoring, it is an explanation of technical debt. (2) This does explain the why of when to refactor - to a business person. Honestly, they don't care about the technical reason, you do. They want a justifiable reason you are working on something other than the next feature that will drive sales. This is why most programmers can't talk to their boss and complain the boss is stupid. They are not stupid, they just have different drivers than you.
Oct
15
awarded  Yearling
Jul
27
comment Blaming the ills of today on the technical debt of yesterday
@Ben - you are absolutely correct. As with all analogies, this one breaks down under a microscope. However, the comparison is still solid on a high level. It essentially dispenses with the details and talks to management on their level - as a business problem, not a technical problem. Essentially any long-running project accumulates a certain amount of technical debt and as such it means there is an added expense to development as time goes on. Since this is hidden (and not even well understood), it is in everyone's best interest to make sure it is talked about.
Jul
27
awarded  Good Answer
Jul
27
awarded  Mortarboard
Jul
27
awarded  Nice Answer
Jul
27
comment Blaming the ills of today on the technical debt of yesterday
@maple_shaft - see my answer. Sometimes things in life are no ones fault and are just to be expected.
Jul
27
answered Blaming the ills of today on the technical debt of yesterday
Jun
15
comment Providing Estimates When working With Unfamiliar Technology?
Giving an estimate on something you have never done is, in all practicality, impossible to do with any precision. I recently gave this analogy when asked how long something would take when there were a lot of unknowns: "Imagine you are walking out in the countryside at night. It is pitch black. You need to walk one mile overland. You know which direction you need to go, but you only have a lantern that illuminates ten feet. You have no idea what lies ahead of you: field, river, mountain. Given this, you can make educated guesses, but ultimately you are subject to things outside your control"
Apr
8
comment Is job hopping the best way to keep moving and learning at work?
3 years is plenty of time to learn sociological and relationship skills. As a matter of fact, I would argue it promotes sociological and relationship skills and that longer than 3 years actually stunts personal growth.
Apr
5
comment is it Ok to have a time for familialization of technology and tools once a project starts
I think that reading a tutorial beforehand is not "slacking". I learn best by reading documentation first. I am one of those kids who got a new toy and actually read the directions before playing with it. I usually had a lot more fun with it too, because I knew things that were non-discoverable otherwise.
Mar
12
comment How many hours can you be really productive per day? How?
+1 for sleep. If I get consistent sleep I can focus for 8 hours. If I don't, I get easily distracted and bored. I think sleep is the single most under-rated factor in productivity.
Mar
7
answered How should I manage my time?