I love the concept of technical debt. The problem is when you're talking to someone that has simplistic views of debt (like all debt is bad).

I'd be OK with that bias, if discussing with management.

But then I'd say you have bigger problems with your management.

I don't know how many times I've heard something similar to:

Developer: <Explains the concept of technical debt> So that's why we need to do refactoring X now!
Product Person: Ok, we'll pay it off later because we need feature Y now. I don't care what it takes.
Developer: ... But debt!



(And I make no claims to the sincerity of the people playing the role of the product person).

I come up with a work project to show experience and do a deep dive mostly on my own.

On learning being painful, it is and generally speaking it is getting more difficult because complexity is increasing. My take FWIW.

If anyone knows of a skilled JS developer who would like to work in a London startup please feel free to PM me, looking for someone to help develop a JS application starting next year. Can afford to pay competitively.

I think the concept is good and valid but without someway to quantify the extent of the indebtedness it is a hard sell. Of course tracking it from the gitgo is different than making an argument when it is a foreign concept, never used previously. Developers have a tendency to want to rewrite and "gold plate" software so dire warnings from developers sometimes aren't taken that seriously.

Well the good news is we always start projects with the rosiest possible picture of when requirements will actually be ready. So when they inevitably are not ready by the time we expect, we have time to work on "Sprint 0" stuff – like implementing new technology.

Technical surplus I guess. Just as valid a concept as technical debt.

It basically comes and us developers putting our foot down and saying "I'm going to do this right. Period.". Fortunately all of the key core developers where I work will do that when necessary. Although often that just means us working a lot more hours to do it right – as opposed to getting extra time.

And we usually get a little dead time between projects to implement a lot of the upgrades/refactoring we want. Although we did go about a two-year stretch there with no break – that kind of sucked.

I think developers are poor salesmen - and that's why it often ends up with a "putting a foot down" sort of situation. Things that have "A right way" have a right way for a reason. And when you're not doing them there are usually actual problems that come up that you should be able to point to as real problems that need solving. But often developers are bad at tying "the wrong way" to actual business costs and metrics.

The trick, especially in an agile environment, is to figure out the smallest things you can do that shows value and moves you in the right direction. Need to add testing - start with one test on a bug that keeps coming back up. Want to refactor some really bad code - show the past stories that have taken a long time to implement and include some of that refactoring time in the next story that adds a feature there. And so on.

Obviously, this doesn't work in all cases or in all companies. But I think it works way more often than people realize.

If you combine this approach with making major infrastructure/technology investments in occasional down times or when starting new major features you'll actually get pretty far, imo.

Our company has pared down to like 5 (overworked) core developers, a few contractors and a bunch of onshore/offshore infosys devs. One advantage of this is we pretty much have all the leverage. If we tell them it's going to take a little longer to do it the right way, or they can put someone else on the job - there is no one else to put on the job. So they have to live with it. Also they know us well enough to know we're not future-tech-happy.

Our managers just want to get through the day as quickly as possible - which has its pros and cons. One pro is they basically leave all tough technology decisions up to us (minus the really big ones like what platform to use).

I'm far from an expert web programmer, but today I had to figure out what was causing our site to be unbearably slow in Chrome (and no other browser) and it only took me about 2-3 hours because of how awesome the development tools are these days.

You can set Chrome up to continuously re-render your page showing you the time its taking to draw it in the corner. The best part is you can then tweak elements or even the CSS source files to see the effect it has on the drawing time. So all I had to do was a binary search style deleting of css to narrow down the problem to an exact line.

Most of you guys probably already knew about this, but I'm officially blown away.

what was in the line?

It was crazy. It was a box shadow css property where I just changed the value by a pixel.

how big *was* your box shadow?

Our primary client-side bottleneck now is CSS performance. We have too many layers and too many calculations going on. We're chipping away it it but no one really has time to fix most of it.

Chrome DevTools are pretty sweet these days. I see Firefox released a Developer Edition the other day, haven't checked it out yet.

I had to debug a problem appearing only in IE11 the other day and can report that IE DevTools are still the purest aids.

What do people think of the whole bus factor phenomenon? I realized today after reading some articles about it that one of the reasons I'm so tired of my current position is because I've absolutely critical to my team of ~10 for the last 12 months. I'm not being cocky, there's literally no one else who knows anything about CSS or JS at all and who knows about HTML. If/when I get bused its going to completely blow up their schedule for 1-2 months as the project I'm working on consists of ~6k lines of OOP JS and SASS entirely written by me that no one will have any sort of clue about at all. I'm just exhausted at this point.

The main signs that you've become difficult to replace are 1) you're asked to hire junior employees to delegate your work to and 2) you're paid extremely well. Being assigned tasks that you don't want to do or being tired and exhausted are signs that you're perceived as replaceable. If you're so irreplaceable that the bus factor is reasonable analogy, your employer would be going out of their way to make your life comfortable.

Yea, but some employers are just ****ing idiots, no?

Basically what candybar said.

Just about everyone in my department is irreplaceable, and honestly, it is not a good place to be in. At some point, each one of us had to stick to our guns and put our jobs on the line. One person in particular attempts to use this state to gain advantage in terrible ways.

What's missing in your posts is gratitude. I mean, you threw your recruiter under the bus and you have no sense of remorse about it. Your manager even knows what you did, and that can't look good for you. You are also new to this industry, and in order to get a job with your experience (who gives a **** if you know OO JS and CSS), someone, or a group of people, took a huge risk on you, and yes they know it, whether you think they know it or not. It doesn't matter if you like your job, your employer, or your recruiter. Without them, you wouldn't be able to work.

With that said, the best thing you can do is have a frank conversation with your bosses. Let them know you aren't happy and see if they aren't willing to make accommodations. If you are truly irreplaceable, they will accommodate you. Assuming you are truly irreplaceable, the last thing you want to do is up and leave without giving your employer an out. This makes you a jerk, and you don't want that painted on your back.

Neither 1 nor 2 apply but there's no one else who can do the work, at all, so my only conclusion is what Kato said. I mean I'm not crazy right, a professional development team of ~7 developers, a manager, 2 QA, 2 BAs, and a PM should be busproof right? If I had a jr developer under me who did stuff I can to at least some degree my job life would be way happier as I could offload some of the BS, but that hasn't happened.

Dave I don't think I'll be taking career advice from you thanks but I will just add this:

I owe them nothing. Thats what the money is for.

And you called me a jerk?

eh? I don't think you're a jerk. I don't think of you at all.