I've been using this for a few months and it's great. The wiki-like connections, vim mode, and several different ways to look at how things relate make it my go to for notes
When I last wore glasses, I found zenni optical, and got my prescription for $18, which would have been near $200 at a wal mart. They were great, and lasted many years.
I don't have much frustration with tech debt itself. It's a normal, acknowledged, often understood and predictable side effect of moving fast OR weighing tradeoffs.
I actually get pretty annoyed when it's conflated with product debt. I don't know if that has a real definition, but for me that's where your market/audience has grown to need things you did not envision/never built. This is often labeled as tech debt, even though it has nothing to do with your coders. This is an organizational issue, and one I haven't fully conquered yet.
Tech debt should not be accruing every week, it should be a conscious decision. MVP's are riddled with tech debt, intentionally. You want to get the thing out there and start gathering feedback/information, you acknowledge you don't know the right thing to build, and will do so once you have more info.
I'm also annoyed at the junior dev that doesn't take time to understand a system, and shouts that it needs to be re-written. Most times that's just because the dev is junior, or lazy. It's actual tech debt when the system is too convoluted to understand, or you haven't documented.
I have no idea what "sprint commitment" or "manager's power" are supposed to mean. They both sounds kinda sick.
If you know a rewrite is going to be a time sink and catastrophe, why on earth would you do it? Also sounds sick.
Your org should be focused on business results. If you're focused on optics, things are not healthy.
You are not in a race with your competitors unless you're in a market that is itself racing to a commodity. This is a business strategy problem vs an engineering one.
Technical debt seems far less a problem to me if you have a moderately capable software engineering team. It happens, yeah. But as your experience grows you know the proper balance of paying it down vs new work. It comes down to measuring quality of your services from an end user perspective vs how much work on engineering and support teams to maintain the desired quality.
This seems like the worst first take possible for a policy that otherwise seems to have good intentions.
Basically this is pedantry around something that completely does not matter. Every major registrar already provides mechanisms for hiding this info from the general public should you choose to do so.
Seems like lawyering for lawyering's sake. When can we get rid of that?
> that's how long it takes for the company to change too much or for me to lose interest
What's the thing that keeps your interest? What's the change that makes you uninterested?
If you don't want any crunch, seeking out a clock-puncher position at a big corp that does some software development might be a good idea... but that will be MORE boring.
Or... start your own thing that is aligned with your interests?
Why are we giving such a pass that it took till 2015 to even start walling off that information?
Prior to 2015 any facebook app developer could make an app that had a vague one-prompt ask for permissions that gave them nearly everything, and a ton of information on friends.