Show HN: "Who is hiring?" Map - <AUTHOR> http://whoishiring.it/#!/search/Europe/38.7091659023888/-23.356950200000014/2 <comment><USER2> This is awesome. Seriously. I never go through the regular "Who is Hiring?" thread because I don't have time to comb through a humongous list of unfiltered text posts, 90% of which aren't relevant to me. There have been other attempts to format the thing, but this is the best I've seen so far.

One minor bug: I'm seeing a listing titled "\---" that starts with "I am a Junior Front End Developer. I eventually want to go into...". Seems to have picked up a comment by accident and interpreted it as a job posting.

<comment><USER3> It's easy enough to just Ctrl+f for your location name, my biggest complaint is all the entries that don't say what their company does.

It's all well and good that you're in my city and I'm familiar with the tools you use, but if you can't be arsed to include a single sentence description of why your company exists, I'm much less likely to care. Bonus points if your description isn't buzzword laden nonsense.

<comment><USER4> Descriptions would be great, but without regex support and a list of every town in your area, Ctrl+F doesn't really help.

A map is a much nicer alternative to trying "San Francisco", "Bay Area", "SF", "Oakland", "Berkeley", "Silicon Valley", "Palo Alto", "Menlo Park" etc..

<comment><USER3> Ah, I imagine that problem is worse for that area. "Seattle" is pretty much just "Seattle".

<comment><USER5> It's not just there. I was searching for London, Reading, Cambridge, Guildford etc, then also for any major city in western Europe.

United Kingdom, England, Britain...

The map is loads better :-)

<comment><USER6> I happen to live in Guildford. Are you local?

</comment></comment></comment></comment></comment></comment><comment><USER7> This is pretty cool. I'd advise not changing the URL with every map movement and instead let the user generate a linkable URL upon demand. This created quite the enormous history list after only using a few minutes.

<comment><AUTHOR> To be honest this didn't cross my mind. But true, I should do something about it.

<comment><USER8> You can keep your urls sharable and avoid breaking the back button by storing the map state in the url hash.

something like: `location.hash = '#map/' \+ mapLat + '/' \+ mapLng + '/'\+ mapZoom;`

Here's an example of one I made for a client recently. [http://www.btforasthma.com/find-a- clinic?ctry=US&state=NY&lo...](http://www.btforasthma.com/find-a- clinic?ctry=US&state=NY&loc=10001#map/40.78079/-73.97894/40.72332/-73.94897/10)

Incidentally, if anyone is looking to hire a consultant with mapping experience, hit me up.

<comment><USER9> That still creates a history state, so if you make 10 map moves, you have to click "back" 11 times to get back to the previous page.

replaceState() works a lot better:

[https://developer.mozilla.org/en- US/docs/Web/Guide/API/DOM/M...](https://developer.mozilla.org/en- US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history#The_replaceState\(\)_method)

</comment></comment></comment></comment><comment><USER10> Fusionbox (Denver Colorado) is displayed in a Dutch Themepark. On top of the rollercoaster 'The Python', because their location is 'Python'.

[http://whoishiring.it/#!/search/Europe/51.6468119/5.05352849...](http://whoishiring.it/#!/search/Europe/51.6468119/5.05352849999997/15) [http://rcdb.com/897.htm](http://rcdb.com/897.htm)

<comment><AUTHOR> Thanks for this. I will fix it.

This may happen. I was trying hard to get the all the locations right, although number of formats used may confused things.

Although here Python was recognised as Location, and came before the real Location.

<comment><USER11> The one for Scribd is wrong too. [https://news.ycombinator.com/item?id=9816112](https://news.ycombinator.com/item?id=9816112) is identified as a job in Berlin.

I think the mods should enforce some address formats to make things more convenient for tools such as yours.

<comment><USER12> If you zoom in, it is actually placed in Frankfurt an der Oder. I'm not sure how they got THAT idea.

<comment><USER13> If you zoom in further, it is actually placed Slubice, Poland, just across the border from Frankfurt an der Oder ;) Still no idea how it got there, though.

</comment></comment></comment></comment></comment><comment><USER14> Bug Report #1:

1\. Scroll to the bottom of the list on the right.

2\. Click to expand the final item in the list.

3\. There is no visual cue that you can now scroll down further to see the expansion. The first item in the list that I click on was the final list item, and I thought that nothing had happened (Note: This could just be an issue with OSX's hidden scrollbars. I can't see if you've disabled it on all platforms, but lots of devs are on OSX).

{edit} I guess I should mention my suggestion. If you're already scrolled to the bottom of the scroll area, and then you take an action that expands the scroll area further down, your position in the scroll area should move to the "new" bottom. There are obviously caveats to this though (e.g. if scrolling to the new bottom would scroll your old position off-screen, this may be disorienting to the user depending on the content and other visual cues). {/edit}

Bug Report #2:

I tried to click the "firstname.lastname@example.com" at the bottom (as it's a clickable link), and was taken to a CloudFlare page about how it's hiding the email address for "protection." The issue here is that the link text itself is the email address, so nothing is really hidden (except maybe from poorly written bots crawling the web).

NOTE: This is _not_ meant to be negative or down on your work. It's really great, I just like to take the time for some constructive criticism when there the authors' attention is on the threads (and it's not a e.g. Github project -- that I can see -- so I can't really just open an issue in the bug tracker).

<comment><AUTHOR> Thanks for the feedback

ad 1. Yes, I think you right about the this being a bit confusing. Although I'm not sure if scrolling to bottom, would be ideal as well. Although I will try to test your suggestion. Maybe will feel right.

ad. 2. Fixed. This was default for CloudFare (they are awesome)

ad. NOTE. No worries, all the feedback here was great and supper useful.

<comment><USER15> Maybe have it as an accordion.

</comment></comment></comment><comment><USER16> This pretty much sums up the state of the UK job market : [https://imgur.com/qLzxV7U](https://imgur.com/qLzxV7U)

<comment><USER17> it's not just quantity, either. In the UK developers make like £25k (which is $39K). I'm not even joking -

[http://www.payscale.com/research/UK/Job=Front_End_Developer_...](http://www.payscale.com/research/UK/Job=Front_End_Developer_%2f_Engineer/Salary/2b122b63/PHP)

That's £25k for someone with both front-end and PHP back-end skills. Less than 10% of these jobs reach $54K - according to that, if you're earning $54K in the UK you're in the top 10% of developers.

That £25k median isn't all that much more valuable than, I don't know, a secretary, the median of whom earns £19k (i.e. only 20% less) and normally requires no skills other than the ability to type and be organized. [http://www.payscale.com/research/UK/Job=Secretary/Salary](http://www.payscale.com/research/UK/Job=Secretary/Salary)

whereas a front-end engineer with php _literally_ programmed Facebook (talking about Zuck), or can program the next one. It's kind of sad, really.

<comment><USER18> And programmers in the City make >100k. Not all of them, of course, but many. And 80k is average.

<comment><USER19> That still seems low given the cost of living in London + comparing to finance devs in the US in similar markets.

<comment><USER20> I imagine he's talking in £ not $.

<comment><USER19> I guess I had my conversion rate a bit wrong, 80,000 is about 124891.20 according to google. That seems about on par from my anecdotal evidence.

<comment><USER5> When I told my mum my salary she dropped the phone. It's roughly double what she was earning at the end of her career as a senior subject teacher, and more than what the headteacher at her large school earned.

In don't work in the City, but they also get bonuses (in return for long hours?). They also get 25-28 days holiday, as is standard, unlimited sick leave etc, which should be taken into account when comparing with the States.

[http://www.nasuwt.org.uk/consum/groups/public/@salariespensi...](http://www.nasuwt.org.uk/consum/groups/public/@salariespensionsconditions/documents/nas_download/nasuwt_012875.pdf)

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> So, apparently there are a good number of tech jobs in Java Virginia, USA

[https://en.wikipedia.org/wiki/Java,_Virginia](https://en.wikipedia.org/wiki/Java,_Virginia)

I suspect those might not actually be there.

<comment><USER22> the small town of Alabama, NY also representing

[https://news.ycombinator.com/item?id=9812941](https://news.ycombinator.com/item?id=9812941)

"Decatur, AL / NYC"

<comment><USER23> With the sheer volume of posts in WiH it's serious work to Ctrl+F your way through each post and find something based on your criteria. Wish there was a way to normalize that data somehow.

</comment></comment></comment><comment><USER24> This is an awesome tool.

I wonder if whoishiring would consider asking future job posters to format jobs specifically -- maybe JSONify the key details -- so it's easier for tools like this map to scrape.

<comment><AUTHOR> There is a note here [http://whoishiring.it/#!/add/](http://whoishiring.it/#!/add/) about suggested format.

Although "Who is hiring?" has its own tradition and flexibility. So formant shouldn't be enforced be some tool that maps job posts :)

</comment></comment><comment> mike-cardwell The job-description text on the right hand side isn't wrapping for me, meaning I can't read most of it unless I double click to select all and then copy/paste it into a text editor.

I'm using Firefox 39 on Debian.

EDIT: If I change your "white-space: pre" to "pre-wrap" or "pre-line" that fixes it.

<comment><USER25> Same, with Firefox 38 on a recent Ubuntu. The same fix works.

</comment></comment><comment><AUTHOR> Thanks for the feedback so far.

It looks like the biggest issue is guessing locations. I have few ideas how to improve it, although fixing it may be hard. Number of possible formats is huge, and event then the same format could be two different things eg. multiple locations (London, Berlin) vs location with state (San Francisco, CA)

I was trying fix most of the places posted in comments here.

For those asking how I map locations. I'm using text tagging with named entity recognition approach.

</comment><comment><USER26> Can you allow users to submit location corrections please. You've got a job that's in Canberra smack in the middle of Australia.

<comment><AUTHOR> Ok It looks like this is the biggest issue, I mean guessing locations. This might be hard, I'm using named entity recognition approach, although even with this is not that perfect. Also Is really common to put more than one location, in different formants.

I'm planning to add UI widged to flag post as misplaced.

Here the first location appears as Australia and isn't followed by any city, also the next entity is not location. So we are done. Australia is the location.

Said that I will fix the job position manually.

<comment><USER27> First, nice work - this is the kind of user interface and lookup tool that could serve as an great example.

Next, great job of taking the comments constructively.

Last, lest anyone think that the next Silicon Valley is on the King River east of Fresno, I think that cluster of 8 is centered in the location "California".

<comment><AUTHOR> Thanks. Finding locations is not perfect, I'm aware.

I will try to come up with something more accurate before next "Who is hiring?"

</comment></comment></comment></comment><comment><USER28> Grid Versions

[http://www.jobdensity.com/QueryGrid.aspx?q=936&t=Software%20...](http://www.jobdensity.com/QueryGrid.aspx?q=936&t=Software%20Engineer&qt=6/29/2015%208:51:25%20PM)

[http://www.jobdensity.com/QueryGrid.aspx?q=938&t=python&qt=6...](http://www.jobdensity.com/QueryGrid.aspx?q=938&t=python&qt=6/29/2015%209:01:46%20PM)

[http://www.jobdensity.com/techsector.aspx](http://www.jobdensity.com/techsector.aspx)

<comment><USER29> Thanks for that link! It's interesting to check it against my site's jobs-per- location data: [http://techjobs.me/stats/city_stats](http://techjobs.me/stats/city_stats)

At a glance, there doesn't seem to be that much of a correlation in the respective sites' data sets, but that's probably partially explained by the fact that we filter out all recruiters and certain large companies, outsourcers, and consultants (which gives the startups a heavier weight in influencing the rankings).

</comment></comment><comment><USER30> Your post job page[0] states whoishiring posts every first day of the month. However the post actually happens every _first weekday_ of the month. [1]

[0][http://whoishiring.it/#!/add/](http://whoishiring.it/#!/add/) [1][https://news.ycombinator.com/user?id=whoishiring](https://news.ycombinator.com/user?id=whoishiring)

<comment><AUTHOR> Noted. I will fix it.

</comment></comment><comment><USER31> Ha! There's a small town in southern Ontario called Ajax and it seems to have placed a job there with AJAX in the description. This is a reasonable error though I think. Very cool overall :)

[https://news.ycombinator.com/item?id=9816153](https://news.ycombinator.com/item?id=9816153)

<comment><USER32> Also, there are four jobs with the text "Amazon" in the listing being shown on the map in Amazon, Montana...

<comment><USER33> And a Scala job has been placed in a town called Scala in Italy, not far from Naples.

</comment></comment></comment><comment><USER34> Just let zoom with double click in the map and you'll make it

</comment><comment><USER35> Wow, only 5 out of the 50 jobs in London are offered remotely, I thought the Internet was meant to change things!

<comment><USER19> I think the debate is still open on the benefits and drawbacks of remote jobs. It's going to take a long time to change the culture.

</comment></comment><comment><USER36> Pretty neat! Along with the better location accuracy / being able to modify them that people are suggesting it would be nice to improve the combination circles so that they're over their respective areas. For instance if I zoom in at just the right distance over Washington D.C. it'll show a circle above the city with a number in it and you can clearly see Baltimore as well but Baltimore has no circles until you zoom one more level at which point it then separates the circles.

Example: [http://imgur.com/a/A3Xtq](http://imgur.com/a/A3Xtq)

Also being able to double click on the map to zoom would be nice!

<comment><AUTHOR> Thanks for the feedback.

The fist issues sums as the clustering algorithm, which currently is not prefect. Current clustering works on a grid. So it's possible to have two close dots not being clustered, because are leaving in the different cells of the map grid. Although I have alternative one which will try soon.

Map zoom shouldn't be a problem.

</comment></comment><comment><USER37> THANK YOU for being able to search for remote jobs. That is awesome!

Now some feedback - browsing the map/zooming in bloats out my back stack. A couple back clicks is ok, but it took 20+ just to get back to where I was.

</comment><comment><USER38> Saw this and had to sign up to post this comment:

I'm basically building this the other way round by listing programmers worldwide. Currently, you can view the top 15 programmers of specific cities along with projects and language statistics, but I plan on adding a worldmap for the most influential programmers worldwide. To see a city, you can check San Francisco for example [http://programmermap.com/area/san-francisco-ca- usa/](http://programmermap.com/area/san-francisco-ca-usa/)

</comment><comment><USER39> Really awesome tool - I'm not sure how (or if) it handles multiple locations, but the listing for TrueCar gets plotted at "Santa Monica Way, SF" rather than Santa Monica _and_ SF.

<comment><AUTHOR> Thanks.

I doesn't, I don't think I know how to handle them right now. The number of possible formats for locations that people use is already huge. Trying to figure how to split them may be hard to solve.

</comment></comment><comment><USER40> Nice job. You may want to take a look at [https://github.com/gaganpreet/hn- hiring-mapped/](https://github.com/gaganpreet/hn-hiring-mapped/), who wrote a python script to extract location info from who's hiring posts. (Demo at [http://gaganpreet.github.io/hn-hiring- mapped/src/web/](http://gaganpreet.github.io/hn-hiring-mapped/src/web/))

<comment><AUTHOR> I'm aware of its existence. Even asked a question about license. No response yet.

As for location algorithm. It looks less robust than what I'm using right now. Although I might be wrong. Haven't tested since can't use it.

<comment><USER41> Author of the Python script here. Sorry I didn't get around to adding a license sooner. I just added one.

</comment></comment></comment><comment><USER42> You beat me to it. I was working on this and downloaded all the items using firebase API. Great job. How did you parse the location? I thought that would be the hardest part.

<comment><AUTHOR> I think you are right. It's pretty hard. I'm using NER approach [https://en.wikipedia.org/wiki/Named- entity_recognition](https://en.wikipedia.org/wiki/Named-entity_recognition)

There is a room for improvements.

</comment></comment><comment><USER43> I would love it if you can add a "Reset" function which would zoom out the map to default state. After digging in deep enough its a pain to get back to zero state.

</comment><comment><USER44> You've got a few problems with map placement. A firm in Grand Rapids and another in Traverse City are both listed in the Michigan woods between the two cities.

</comment><comment><USER45> That's why I want to move away from Latin America...

About the tool itself. Great work! It really helps saving us time when looking for opps within a certain region.

<comment><USER46> It's not only LA, everything but USA, UK and a couple of other Europe countries is empty, I think that's because the kind of start-up mentality fits better in those areas, there are plenty of opportunities in other parts of the world, not to mention that many of job offers listed here allow remote applicants =). This is a better HN job listing though.

</comment></comment><comment><USER47> This is great. I've posted about this before, but my biggest pet peeve with /jobs is a lack of location in the title. Presently there are 18 jobs posted there, only 1 (GoCardless - London) mentions a location in the title.

I live in NY and the difference in an office in Brooklyn / Midtown would be the difference in me applying to the job. I imagine East Bay vs. Palo Alto is a similar story.

<comment><USER48> I'm in the South Bronx and looking to move northward, so anything that's in Brooklyn is a no-go for me - it'd be quicker for me to get to some places in New Jersey. So I definitely feel ya on this one. I think rent is cheaper and a lot of devs are living in Brooklyn these days, so I'm seeing more dev shops opening up down that way, so location is a big deal even when you're in a big metro - emphasis on _big_. Getting from one end of NYC to the other can cost you 2+ hours (each way) depending on trains and whatnot, so it's no little quibble.

</comment></comment><comment><USER49> I've tried it and the work location on the map seems incorrect.

I'm looking at a specific location, eg: Philippines, but the work location that's been pin in the map are from the US.

Pls. see attach link: [https://dl.dropboxusercontent.com/u/12912452/map_hiring.jpg](https://dl.dropboxusercontent.com/u/12912452/map_hiring.jpg)

<comment><AUTHOR> thanks for the report. Location extraction algorithm is not perfect. Will try to make it better over time.

</comment></comment><comment><USER50> Where is this data sourced from? Are you pulling it from somewhere or does it need to be manually entered by recruiters?

<comment><AUTHOR> This website "Who is hiring?" series.

</comment></comment><comment><USER51> This is great. It's crazy how huge the Who is Hiring thread has become since it began on HN. Browsing it has gone from a quick scan through to a time consuming process, even using Ctrl + F and other shortcuts.

I've been looking forward to a tool that would make going through the posts easier, so very happy to see this!

</comment><comment><USER52> [http://whoishiring.it/#!/search/Europe/42.6931351/-73.372054...](http://whoishiring.it/#!/search/Europe/42.6931351/-73.37205489999997/9)

Berlin, NY is being shown here. Text from post is "Berlin, NYC,..."

Cool visualization.

</comment><comment><USER53> Unite (Los Angeles, CA) shows up in Oaxaca. [http://whoishiring.it/#!/search/Europe/17.116676976573096/-9...](http://whoishiring.it/#!/search/Europe/17.116676976573096/-96.75052172142637/15)

</comment><comment><USER54> Nice.

I think there is some bugginess in looking at remote jobs:

\- In the "Europe" search with remote set to "yes" I see my posting for "Automattic"

\- Change the location to "Boston" and it is not there (and neither are any other remote jobs.

\- Also, shouldn't remote be defaulted to 'yes' :)

</comment><comment><USER55> Great tool. Location is one of the biggest factors for most devs as they decide where to apply.

</comment><comment><USER56> This is a great presentation tool of YC jobs. I really like how the text search is based on mapview. Would be nice to have the jobs distributed by zip code. SFO and London seem very clustered. Great work.

</comment><comment><USER57> It gets Vancouver, BC and Vancouver, WA mixed up. It should assume Vancouver means BC. Otherwise, nicely done! Have you thought about how to do REMOTE/location independent jobs? And for freelancers?

</comment><comment><USER58> This breaks the back button.

<comment><USER59> Broken on Version 43.0.2357.130 m of Chrome.

</comment></comment><comment><USER60> I'm curious as to how you're placing these. 21 jobs in downtown Seattle, but 2 specifically in Ballard (neighborhood), but I didn't see mention of Ballard in their job posts.

</comment><comment><USER61> I'm floored by the wide geographic range of listings. Sure, the gross majority are in SF, NY, & London (all English-speaking cities to boot!) but Zurich? Belgrade? Maui? Wow.

<comment><USER62> Yes, it is quite the variation. I know I have recommended posting on this thread to anyone looking for tech talent. I haven't seen a demographic survey of the HN population, but from my anecdotal experience it is far wider than the SF/NYC tech scene.

The Maui opportunity is, unfortunately, just an unpaid internship (they are upfront about it in the listing at least). I wonder what kind of uptake they got...

</comment></comment><comment><USER63> What interests me the most is how some states seem to almost repel the kinds of startups that would post on HN. The northern midwest looks particularly bad on this map.

</comment><comment><USER64> First of all awesome work.

However it seems the keyword 'C++' doesn't work in the "Text search feature", it seems the '+' is stripped from the keyword.

<comment><AUTHOR> Noted. Will try to address it before next "Who is hiring?" post.

</comment></comment><comment><USER65> Now for a site to help college grads to see who is hiring.

</comment><comment><USER66> This is great. I noticed a lot more exposure based on the emails coming in. Also awesome to see other companies in my city who are hiring and on HN as well.

</comment><comment><USER67> It'd be cool if it'd show a precision circle (a la Apple Maps) rather than make it look like 49 London companies are in exactly the same spot.

</comment><comment><USER68> I didn't look through the listings in that much detail, but I did notice that the one listing in Canada is on the wrong place on the map.

<comment><AUTHOR> I'm working on the new alg. to extract location. Next "Who is hiring?" should be way more precise.

</comment></comment><comment><USER69> I built something like this a while back at setonia.com, solved a lot of your problems you are seeing, lmk if i can help somehow.

</comment><comment><USER70> As Portuguese I wonder why Novoda was placed on the country if they are listed as LONDON/LIVERPOOL/BERLIN company.

</comment><comment><USER71> I was really confused about the middle-of-nowhere-Kansas tech hub until I realized it's just the middle of the US.

</comment><comment><USER72> Thanks for doing this!

I really enjoy the _locations_ listed in the HN threads, so this is perfect for me!

</comment><comment><USER73> Great job! I specifically enjoy the ability to filter by "Remote". What did you use to build this?

<comment><AUTHOR> Angular JS for the UI, Python for the tools, Elasticsearch for the search.

</comment></comment><comment><USER74> The difference between SF Bay Area and Los Angeles is pretty striking with 241 vs 5 listings.

</comment><comment><USER75> This is awesome!!! The idea of plotting this information on maps is too good.

</comment><comment><USER76> Great work! This will be helpful to me and I'm sure a lot of others.

</comment><comment><USER77> LOVE this. So cool. Nice and simple. The way shit's supposed to be.

</comment><comment><USER78> Call me a nitpicker, but this the URL looks like an Italian jobs site.

</comment><comment><USER79> Excellent work! Why are there so many startups in San Francisco?

</comment><comment><USER80> Is this open source? On Github or anything like that?

</comment><comment><USER81> Classic "why didn't I think of that"

</comment><comment><USER82> Is the source available for this awweessommme app?

</comment><comment><USER83> Sad to see Africa so empty!

Great job! :)

</comment><comment><USER84> Zillow meets Indeed.

</comment><comment><USER85> Great job! Thanks :)

</comment><comment><USER86> thanks for doing this. much easier to digest.

</comment><comment><USER87> No New Zealand :(

</comment><comment><USER88> Pretty cool!

</comment><comment><USER89> hello!</comment>


Verne – An experiment in social computing - <AUTHOR> http://pointfree.uk/

<comment><USER2> Your crypto currency idea reminds me of something I'm working on (very slowly) [http://www.wired.com/2014/07/document- coin/](http://www.wired.com/2014/07/document-coin/)

<comment><AUTHOR> Nice. I found this paper on the topic by Ryan Fugger of Ripple: [http://archive.ripple- project.org/decentralizedcurrency.pdf](http://archive.ripple- project.org/decentralizedcurrency.pdf)</comment></comment>


Activists Urge Clinton Campaign to Challenge Election Results in 3 Swing States - <AUTHOR> http://nymag.com/daily/intelligencer/2016/11/activists-urge-hillary-clinton-to-challenge-election-results.html?mid=facebook_nymag <comment><USER2> The only problem with a Clinton win now, if they can prove fraud, is it will be the most difficult presidency ever. Hostile house, hostile senate, hostile governors. It'll make the Obama years look like good times.

Sadly this isn't something you can win. If you win you just lose in a different way.

<comment><AUTHOR> It's a strange one indeed

</comment></comment><comment><USER3> Previous discussion: [https://news.ycombinator.com/item?id=13018675](https://news.ycombinator.com/item?id=13018675)

</comment><comment><USER4> Interesting article, but the title of this seems a little odd.

<comment><USER5> It's a Hamilton reference. Mods will change it.

<comment><AUTHOR> true, sry</comment></comment></comment>


The Minimalists want you to be happy with less - <AUTHOR> https://www.thecut.com/2017/10/profile-the-minimalists-ryan-nicodemus-and-joshua-millburn.html <comment><USER2> I've always found the most joyous part of consumerism is the researching for a particular product pre-acquisition, rather than the product itself post- acquisition.

<comment><USER3> It is the most engaging part, but almost to the point of obsession to me. So much that I often have to tell myself, especially with electronics/technology, "just find a good product for a reasonable price".

<comment><USER4> Channel your obsession! I'm the same way and it grew into the most comprehensive database of flashlights around: [http://flashlights.parametrek.com](http://flashlights.parametrek.com)

<comment><USER5> That's very inspirational! I've often thought of putting my useless but extensive knowledge about something obscure to good use, but never did.

</comment></comment></comment></comment><comment><USER6> It's the same kind of panacea movement that takes root with every generation that's about to leave youth behind and enter their scary 30s. Today it's the Minimalists. Before that it was environmentalists, yuppies, conservationists, suburbia... The list goes on.

You reach a point in your life where you start to question what you're doing it all for, and think about what it is you really want and need. Your values become more conservative, and you feel the need to attach to a social movement of the times.

It's also interesting to note that this transition always involves a moral dimension, including the judgment of those not fully on board with your movement of choice, and also competition with those who ARE on board.

Southpark's "smug alert" is particularly apt. [https://www.youtube.com/watch?v=gXZeq9eXAys](https://www.youtube.com/watch?v=gXZeq9eXAys)

<comment><USER7> > It's also interesting to note that this transition always involves a moral > dimension, including the judgment of those not fully on board with your > movement of choice, and also competition with those who ARE on board.

Sorry to call out your strawman here. I've followed the minimalism debate for a while and I hardly anywhere hear so often things like "this is no competition", "this is what I feel works good for me, but you don't have to do it", "if you like your books keep them" etc. What you claim is largely not happening, apart from maybe some fringes of the movement.

<comment><USER6> Hmm, ok, let's use a small sample from this very thread:

Karma judgment (the zen master): "What we call minimalism comprises people who maximalize meaning, value, importance, and purpose."

Competition: "My girlfriend and I are very minimalist (err... maximalist?) owning only a few outfits each (no accessories), and just the bare necessities of home items. If we find something has no utility, it gets donated or trashed."

The True Scotsman: "Just to note, 'minimalists' are almost universally hated in every minimalist community I've seen and I would really not take them as any soft of spokespeople for minimalism."

Moral goalpost: "It sometimes amazes you how little you need to be happy yet everything we do is to get as much as possible."

<comment><USER8> Yes, probably some drug or kind of simulation is enough. /s

The question is ill posed since our brains are not wired for consistent happiness. You are probably mistaking it with being contented which starts by admitting defeat.

And this is all orthogonal to efficiency or productivity which ate important social goals if not strictly personal ones. (Sometimes they partially coincide.)

</comment></comment></comment></comment><comment><USER9> Before I left San Francisco for Asia, I had a studio apartment completely packed with stuff -- three giant suitcases full of clothes, an entire standing bookshelf full of books that I never read, IKEA furniture, and tons of electronics junk that I just never used (Xbox 360, MS Surface Tablet, old PC laptops).

I threw it all away. I must have thrown away $10,000 worth of stuff (well, mostly sold, recycled, gave away, and/or put in Schrodinger's "storage").

My digital footprint is much larger than the physical junk that I had. Now all of my belongings fit into one suitcase.

It was a very relaxing feeling getting rid of all of that junk. I haven't missed any of it.

It's not some hidden agenda that these Minimalists are pushing that they WANT you to be happy with less even though you actually are happier when you have more; I've found that I actually _am_ happier with less (after adopting the right mindset). In massively consumerist cities like SF, there is a ton of social pressure to show off that you have more trendy things than all of your neighbors and to drive that German car, etc. and you just have to use your willpower to not succumb to that pressure.

<comment><USER10> I'm not sure those two are mutually exclusive. You could always have the latest cell phone, laptop, watch, car, etc, without actually having too much STUFF.

Like most people, I have far more STUFF than I need, but even if I downsized to just the stuff I use virtually every day, and really enjoy, would be a total PITA to move.

<comment><USER11> Agree with this! I love researching and acquiring quality things. Doesn't mean I have too much stuff. I love throwing stuff away, but will also enjoy spending a lot on stuff I care about. Quality above quantity.

</comment></comment></comment><comment> w-ll How come 'minimalists' always want me to buy a their book, or go to their seminar?

<comment><USER10> Well, they've got a warehouse full of books. Seems like a great way to de- clutter.

<comment><USER12> Laugh. Out. Loud! XD

</comment></comment></comment><comment><USER13> I make it a ritual. Every year on the same day, I go through all my stuff. Everything! If I haven't used it in the last year, it goes on Craigslist. It's amazing what you can talk yourself into keeping perpetually because "just maybe" you'll need it one day!

<comment><USER14> My problem, as a tinkerer, is that I almost always do end up using something I have laying around one day.

<comment><USER15> I agree. My interests shift back and forth, somewhat unpredictably. I'll work on a given project for a few months, then abandon it for about 2 years. Things that I haven't used in a long time often find themselves imaginatively re- purposed.

</comment></comment></comment><comment><USER16> I'm not a minimalist but I do try to consume less. I see it as some sort of personal hygiene. Just like I barely drink soda anymore or avoid junk food. I see consumerism as a pitfall of our society and at least I try to be aware of its mechanisms. I also try to give a new life to my old things by giving it to less fortunates.

</comment><comment><USER17> I love getting rid of things. I don't care if anyone else does, but I do. I also like acquiring things- but I usually regret acquiring things more than I regret getting rid of things.

<comment><USER18> Same. I also enjoy refactoring code and removing legacy crust.

<comment><USER19> I'm gonna pretend you really mean crust.

<comment><USER20> If you have day old bread it's "legacy crust". And, who wants legacy crust.

</comment></comment></comment></comment><comment><USER21> It sometimes amazes you how little you need to be happy yet everything we do is to get as much as possible.

<comment><USER22> Maybe I'm the weird one here, but I use everything I buy. The only time something I own goes unused is when somebody else buys it for me.

Right now I'm looking to move about 700km. Sure, what little I own is a bit of trouble to move, but it is almost all useful. I'm at the point where having less stuff would mean doing fewer things.

<comment><USER23> I think the problem is drift over time. Maybe you would have used an item, or did use it, but your life has changed--as lives inevitably do--and now you wouldn't use that item under any circumstances. But the thing has become part of your environment, you're used to it, and there's the possibility that the part of your life which motivated you to buy the thing in the first place might come back. So through inertia you acquire more and more stuff, and it starts to quietly sap your energy as you begin to associate subconscious feelings of guilt and frustration with it.

In my book, "minimalism" is often a treatment for the symptom rather than the disease. The real cure is to actively remove items that have a negative emotional connotation, and to hold onto only those things that you either use or otherwise affiliate positive feelings with. (For example, I almost never use my flashlight, but it feels good to know I have it on hand in case the power dies out. That's worth keeping.)

<comment><USER24> > The real cure is to actively remove items that have a negative emotional > connotation, and to hold onto only those things that you either use or > otherwise affiliate positive feelings with.

Is this basically the same idea as "spark joy" from Marie Kondo's books?

[http://www.apartmenttherapy.com/why-keeping-only-the- clothes...](http://www.apartmenttherapy.com/why-keeping-only-the-clothes-that- spark-joy-is-magical-216094)

[https://www.nytimes.com/2014/10/23/garden/home- organization-...](https://www.nytimes.com/2014/10/23/garden/home-organization- advice-from-marie-kondo.html)

<comment><USER23> I took it from "10 Minute Declutter," but it seems like the same idea. It's the only principle I used when cleaning up my own spaces and I'm amazed at the difference just a few months made. My whole state of mind is better.

</comment></comment></comment></comment></comment><comment><USER25> Minimalism is the "being reasonable" of the 21st century. But yea in this consume-oriented world it's very rare and thus news worthy.

<comment><USER24> I second this but would phrase it slightly differently:

Minimalism is critical thinking applied to the ownership, maintenance, management, and lifecycle of objects.

</comment></comment><comment><USER26> There was one line about cutting down the kitchen but the facebook group is private - do these people cook much at home at all? I don't need a lot of gadgets but at minimum one needs a couple of shelves of different pots unless one goes for camping style cooking for every meal - though I would be happy to be corrected.

<comment><USER27> You can cook a very wide range of food with one pot and one frying pan.

<comment><USER28> And at least one cutting knife, a set of utensils, some dishes, a place to store long-term products, spices and leftovers...oh look, I need a shelf now.

Poor families need space to store stuff, because they stock up during good times to go through the bad. My family had a huge basement stocked with pickled vegetables and fruits, bought during harvest when they are cheap to use during winter when everything is expensive. We also had tons of bookshelves, filled to the brim with aged books from parents, cousins and other relatives, because we could not afford buying school materials every year and school libraries were usually picked clean. You need a place to store all the stuff from your parents - your crib, clothes, toys, so you can use them for your kids too...

I don't know how you get around all that with minimalism - from my POV, owning a big house is the best investment a poor family can make.

<comment><USER24> One idea is to not hold onto all of the things. An implication that stems from poverty is an understandable hoarding mentality. I would ask instead, "How could I possibly know whether my child will even want this same thing 5–20 years from now?" then donate it to a thrift store or sell it. And focus on free activities like going to the park over object ownership.

I don't consider myself a poor person but I grew up lower middle class and practiced habits like stocking up on consumables in bulk when they're on sale that you'll definitely use before they expire — things like soap or shampoo or toilet paper. I still practice that today because to me it's fiscal responsibility, but it is easy to go overboard as well. I just always try to optimize for reasonable unit economics which can vary quite a bit from thing to thing. Sometimes buying the cheap disposable version makes more sense than a BIFL.

</comment></comment></comment></comment><comment><USER29> I'm in agreement with most of the anti-consumerism argument. And having spent my adult life living in tiny apartments in NYC and London and moving internationally a few times, I certainly understand how possessions can be a burden.

But still, whenever I read about "minimalism", and people bragging about how they can fit everything they own into a single carry on bag, I can't help think that these are really boring people. It just doesn't seem like a lifestyle that would make any sense for all but a small number of people that fit some very narrow conditions ("pure" knowledge worker, no pets or children, no interest in whole swaths of hobbies and activities).

Eg, I'm a professional software developer to pay the bills. RSI is a potential career ender for me, so I have an ergonomic setup a good chair, desk, monitors, keyboard and trackball. I can't just work on a macbook air in a cafe all the time without risking my livelihood. When I'm not working, I like to do oil painting (which requires an easel, paints, brushes, cleaning supplies, sketchbooks, etc.), I play and record music (so I've got a bass, a couple guitars, a couple amps, pedals, mics, etc), and I like hiking and camping (so backpack, tent, etc. etc.). My partner teaches electronics and builds hardware games and art installations, so our flat is full of soldering irons, heat guns, reflow stations, and stockpiles of components. She's also a musician so she has a small collection of synths and music gear of her own and she likes to do woodworking and build furniture (we don't have room for large power tools in our flat, so she has a membership at a maker space for that) and she likes gardening so we have a ton of plants.

When I think about all the most interesting, creative people that I know, none of them could do the "minimalism" thing either. They do things like arc welding, hardware reverse engineering, homebrewing and distilling, electroplating, restoring vintage motorcycles, sewing, 3d printing, quilting, farming, baking, cosplay, etc. All of which require having a bunch of stuff.

Minimalism is fine and if it works for you and your lifestyle, fine. But I really don't like how it always seems to come along with an implicit disdain for physicality and interests that aren't completely in line with that knowledge worker on a macbook on an empty desk aesthetic.

</comment><comment><USER30> At some point, your shit owns you.

A few years ago, I was forced to move in with my gf (long story) She owned a house, filled with her own stuff. I was left with no option but to dispense with furniture etc. Some was sold, some given away, some donated. I moved in with my clothes, some memento's and heirlooms and some kitchen utensils (just in case it didn't work out).

I moved everything in two loads of my truck. Over the years, theirs been times where I was considering moving out. Not having to deal with all that STUFF is intensely freeing. Call it an awakening through involuntarily minimalism.

</comment><comment><USER31> NYTimes had a decent critique last year of minimalism and the minimalists: [http://www.nytimes.com/2016/07/31/magazine/the-oppressive- go...](http://www.nytimes.com/2016/07/31/magazine/the-oppressive-gospel-of- minimalism.html)

<comment><USER32> It's literally the same author - ha!

</comment></comment><comment><USER26> The family cloth for toilet paper seems less sanitary than not using toilet paper and washing.

<comment><USER33> The correct answer to washing your butt is a "bum gun" or bidet. It's more sanitary, quicker, more environmentally friendly, cheaper in the long run, and less likely to cause irritation. I would never go back to paper.

<comment><USER8> Or just using the shower.

<comment><USER34> Not hygienic IMO.

</comment></comment></comment></comment><comment><USER35> Just to note, 'minimalists' are almost universally hated in every minimalist community I've seen and I would really not take them as any soft of spokespeople for minimalism.

<comment><USER19> Perhaps by 'minimalists' you mean 'The Minimalists', i.e. these two dudes, because that statement is otherwise very odd.

But maybe you thought the article and capital letter weren't adding value to your life.

<comment><USER35> Yes, I meant that, sorry that it was not clear.

</comment></comment></comment><comment><USER36> Minimalism is misnamed: [http://joshuaspodek.com/minimalism-misnamed- maximalism](http://joshuaspodek.com/minimalism-misnamed-maximalism)

If someone doesn't value stuff, does value meaning, and gets rid of the former to maximize the latter, why call attention to and name them by what they don't value?

What we call minimalism comprises people who maximalize meaning, value, importance, and purpose.

<comment><USER37> My girlfriend and I are very minimalist (err... maximalist?) owning only a few outfits each (no accessories), and just the bare necessities of home items. If we find something has no utility, it gets donated or trashed.

That being said, "minimalism vs. maximalism" really seems like splitting hairs here, as I don't think one implies something better than the other or is inherently clearer.

<comment><USER38> But such a form of minimalism won't work unless other people are non- minimalists.

For example, if you find you need a trilobed screwdriver to repair one of your few possessions you'll either have to borrow it from a friend or rent it[0]. Both those options require that someone else be non-minimalist for your benefit.

If all people were strongly minimalist this would have the effect of moving nearly all gadgets into the service domain. Screwdriver-as-service, ironing- as-a-service, yard-brushing-as-a-service. Is that scenario really _less_ consumerist and less stressful than just going out and buying a screwdriver and keeping it in a box in the garage?

[0] or buy it and then sell it when done, which i'll categorise as renting here

<comment><USER39> _if you find you need a trilobed screwdriver to repair one of your few possessions_

Pay someone to come and fix it or just throw it out and get a new one. Being Minimalist doesn't have to mean being frugal.

<comment><USER8> Then the only difference is that you do not keep things you do not use. However it is a misnomer until you minimalize number of possessions to which implies frugality to a point.

Not perhaps in the "buy cheapest" but "buy least".

</comment></comment></comment></comment></comment><comment><USER40> Wow, I really didn't know my natural state of being was catching on.

It's interesting to read how people actively push themselves towards minimalism. I have the opposite problem: if everything I own doesn't fit in an airplane bag, I feel bogged down.

I truly dislike buying things. Furniture shopping is just the worst.

I guess it partly depends on what you value. I value experiences, like travel and live music far more than I value a shiny thing or piece of clothing.

I've been asked advice on how to live without stuff... "How do I start throwing things away?" I don't have an answer. I just don't want whatever it is.

<comment><USER41> Do you have a family or are you single ? Life changes when you are responsible for others.

<comment><USER42> This is such a bad excuse that comes up every single time on such topics. Your life is what you make it. You can perfectly have a modest family life with a limited number of posessions : how about all those families who travel or sail the world ?</comment></comment></comment>


8tracks blocks non US/Canada based users - <AUTHOR> http://blog.8tracks.com/2016/02/12/a-change-in-our-international-streaming/ <comment><AUTHOR> On a related note, if you live in the US or in Canada and would like to continue the development of a command line based client for 8tracks: [https://github.com/dbrgn/orochi/issues/73](https://github.com/dbrgn/orochi/issues/73)</comment>


An Early Tale of the Internet - <AUTHOR> http://bits.blogs.nytimes.com/2012/12/26/an-early-tale-of-the-internet/?smid=tw-nytimesbits&seid=auto <comment><USER2> Somebody please fire the copy editor,

> Last Friday I interviewed Peter E. Hart, an electrical engineer who was an > early artificial intelligence researcher, about one of the first robots, a > machine named Shakey that was designed at SRI International beginning in > 1966.

<comment><USER3> Since it's at blogs.nytimes.com, I assume it's a blog, not a an actual news article that goes through the normal newspaper editing process.

I've seen lots of posts on HN and elsewhere referencing blogs.nytimes.com. Does anyone know exactly what their organizational setup is?

</comment></comment><comment><USER4> Time to dig out the secret sysadmin anti-tarnish/corrosion "Bit Polish" recipe. I'll make a fortune.

</comment><comment><USER5> This is Hart of Duda and Hart, BTW.

</comment><comment> at-fates-hands Ironic so many years after this story, there still exists a huge gap between programmers and non-programmers.

Exhibit A would be some of the Java v. Javascript conversations I have almost daily with my PM's.

</comment><comment><USER6> No mention of depreciation? Plus ça change...</comment>


Three Kinds of Good Tech Debt - <AUTHOR> https://engineering.squarespace.com/blog/2019/three-kinds-of-good-tech-debt <comment><USER2> The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it.

What is good debt? It's taking money from someone, promising to pay them back more money in the future, and using the original money to make _even more money than that_ , so both you and the lender profit.

Good tech debt is just the same. It's taking shortcuts now to save time and get something shipped, knowing that it will cost you more time than you're saving now to fix it later. But by shipping now, you ensure there is a later, with a product that's out there and being used, a bigger team and therefore adequate time and then some to fix the debt _and_ keep improving the product. Everyone wins.

That's the theory anyway. I think mostly where it goes awry in the wild is people forgetting the paying it off part. Part of this deal is you have to pay back your lender - they have to win too. It's just easily forgotten because _you 're_ the lender, so the incentives get a bit conflicted, and you'll keep giving yourself more time. But if the lender ultimitely doesn't get paid back and loses, you lose, and it's a bad debt.

<comment><USER3> One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to.

When you're validating an idea, don't worry about making everything perfect. Worry about validating the idea. Once you're more confident that you're actually gonna do it long-term, then it starts being more beneficial to pay off the tech debt.

<comment><USER4> I think what you're saying is the more common use of "tech debt", basically just using it as a synonym for "bad code". Don't worry about code quality, figure it out later.

It ignores the stronger debt analogy -- sure, there is a high chance that the idea fails. But if it succeeds and, all else being equal, you have taken on a less tech debt to get there, you will be able to iterate on and grow it more efficiently. So to the extent you're taking on debt, it should be an explicit trade-off to increase your chances of proving out the idea. Which is not the same as "don't worry about bad code at all."

From what I've seen, when it comes to talking about tech debt from an early prototype, it's often an excuse/euphamism to be considerate to the people that wrote it. The truth is often that it's just bad code due to them being inexperienced or lacking the skill or discipline to write better code. Which I don't mean as an insult, it seems like there's a strong inverse correlation between the kind of person who's passionate enough about product over tech, and is creative/naive enough to build and validate a brand new product, and the kind of person who understands enough to architect a great system and make the best tech debt trade-offs.

<comment><USER3> I absolutely agree - that's the whole point of the article and my comment. If you're in an experimental space, and 9/10 of your ideas are never going to make it to market, I'd rather spend 1 units of time on each to figure out which one's going to work, and then 20 units of time redesigning it the right way (i.e. 21 units of time to be done), rather than 10 units of time on each to make them all ready for production (i.e. 100 units of time to be done). But those ratios will vary depending on how sure you are about what needs to be done next, so yes - you've gotta weigh the cost / benefit.

</comment></comment></comment></comment><comment><USER5> Two points I really enjoyed:

> Not Fixing All the Edge Cases

We've all seen bugs that occur so rarely, and fixing requires destroying some part of the original design architecture. The ability to acknowledge these types of bugs as not worth fixing is liberating.

> Err on the side of building too little because you can always build more > later. Build things to be easy to throw away and replace;

I find developers tend to really dislike throw away code or temporary solutions knowing they might break in the future. If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later.

<comment><USER6> Writing hacks and throw-away stopgap solutions is generally a bad idea in reality. The only time when it can actually be allowed is when it it concerns a feature that is a pure leaf in the system with nothing else built on top of it. If you violate this rule and build other features on top of shortcuts, two things will inevitably happen: you will have to replace the shortcut with a proper solution eventually (it is only a matter of time) and by the time this happens, the assumptions underlying the shortcut have implicitly been taken on by the code depending on it. This means that you will have to review and replace a lot of dependent code as well.

I have gone through that dance often enough. It ends up being more time consuming than doing it right in the first place each and every time.

<comment><USER7> Yes, it's more time overall, but that's not the point.

From the example in the article, if it would take them 2 months to build a robust email delivery system or 2 weeks to put a temporary hack in place, it could be worthwhile to the business to do the hack if it means they can start user-testing 6 weeks earlier.

Also, if they're still in the product-fit stage of their business development, they might find that the product isn't as useful/worthwhile as they thought, and scrap it after 2 weeks testing. This would allow 6 weeks of overall developer effort to be spent on another initiative.

Just because you know that developing throwaway code is waste, doesn't mean it's necessarily a bad business decision.

<comment><USER6> Is it worth the while when you have to spend more than weeks to do it right later? Again, in general it is not. You are citing a very, very specific business reason as a justification. In 99% of all cases, no good business reason exists to waste more money later. Essentially, this is what you are asking. In your example, it's either 8 weeks total to do it right in the first pass or 10+x weeks total to do it right later when you have the still unquantified extra overhead of not breaking stuff that has been built around the insufficient solution.

<comment><USER8> You have to look at it differently: if you hack something in two weeks, you will:

\- be able to switch to other, more important tasks more quickly;

\- allow the business to better discover what the _actual_ requirements are while they have an MVP solution in place.

Resources are finite: you only have a limited number of engineers, and the business needs to be moving forward. This approach allows you to do so, while mitigating a lot of risks at the same time.

The costs are not lost: they bring back business value in terms of fast progress, and mitigates risks.

</comment></comment></comment></comment></comment><comment><USER9> I like the framing of tech debt as value-neutral; whether it's good or bad depends on how you use it (just like financial debt). Of course, all else being equal, you'd rather have zero debt.

One higher level consideration that's particularly relevant for early-stage startups, is that you often simply don't have time to build the ideal "tech- debt free" solution. Focusing on 80/20 solutions almost necessarily involves adding tech debt. However, if you're mindful about where you take on tech debt, and commit to tapering and then paying it down as your resources grow, then you're more likely to avoid the debt spiral where your development grinds to a halt, due to everything breaking all the time.

One other point I'd make is that a common form of "tech debt" for early-stage startups is simply doing things that don't scale; it's often beneficial to make your domain models flexible so that you can support one-off manual interactions, for example if a new customer appears that requires it. Then automate that thing and constrain the domain actions once you have collected enough use-cases to know what makes sense to forbid.

<comment><USER10> I like to point out as well that it isn't tech "debt" if there's no "IOU". For instance, in the hard-coding example, it's conventional wisdom to avoid hard- coded magic constants for a few reasons including it sometimes is hard to figure out later why a magic constant was used, and in an if/else branch situation like that maybe tough to figure out when you can cleanly refactor those branches. If the case is well documented (it's the date of a given feature release) and the code reasonably factored already (the "off" branch isn't a ticking time bomb bug that needs to be removed after the date in question), then it may be a code smell, but it isn't necessarily an IOU to a future developer (such as yourself), so it isn't necessarily "tech debt", it was just a trade off made at the time. Of course, if a future developer adopts a hard linter rule against that sort of code smell, they may come to see it is tech debt retrospectively, but that's also where the analogy starts to get fuzzy.

(Pushing the analogy to a breaking point: Is adding a linter then, doing an audit and depreciating assets for "tech taxes"? Come to think of it "tech taxes" would be a fun alternative term to add to the "tech debt" family. "Hold on, just paying my tech taxes; npm install, npm audit, and npm run lint.")

<comment><USER11> I have a good example of no IOU. Friend 20 years ago worked on a content streaming platform. They needed a dispatcher and someone wrote one in TCL in a week. Just to get something working. And they never got around to replacing it because it worked 'fine'. Turned out while everything else needed to be hyper efficient and scale the dispatcher not really.

<comment><USER12> An unexpected tech debt jubilee!

</comment></comment></comment></comment><comment><USER13> As I've gotten more senior in my career, I think one of the most enlightening things has been anticipating debt before it happens (in planning/architecting), acknowledging it when it does and then taking prudent measures to minimize it and log it for future refactoring.

It's also been funny seeing managers try to rebrand tech debt with other business speak like "tech health". Debt shouldn't be a bad thing but one that's anticipated and respected.

<comment><USER14> The term "debt" is really helpful. It also explains that while you can pay off debts by taking on other debts, there is a good reason why this is illegal (if done with money) in the real world.

Technical debt in your solution is fine. Running a Ponzi scheme in your solution isn't.

<comment><USER15> _> there is a good reason why this is illegal (if done with money) in the real world._

Erm, it very much isn't illegal. At least not in most places.

Taking on fresh debt to pay off other debt is the very definition of a consolidation loan which is perfectly legal in most, possibly all, jurisdictions.

There are limits of course, like not using a loan to pay the deposit on a mortgage, or simply not lending beyond defined means, but these are set by the bank to manage their own exposure to risk rather than limits set by law. Such limits are merely _encouraged_ by law, via regulatory limits on standing capital compared to debt held and so forth.

<comment><USER16> also basically any 'balance transfer' option on pretty much every credit card ever.

</comment></comment></comment></comment><comment><USER17> Technical debt is a wonderful ally when building prototypes.

Imagine you are building a prototype and you are clever enough to only focus on validating an idea. Having this focus you ignore all best practices and maintainability issues you might tend to out of habit.

What you are likely to end up with is a functioning application that resists change beyond its original goals.

And this is good. It lets you declare technical bankruptcy early enough to avoid painful rewrites on a software that was not meant to exist for long anyways.

<comment><USER18> As long as both sides (developer, management) are aware of this (he says, as his "proof-of-concept" was installed into production directly by his manager with no warning).

</comment></comment><comment><USER19> Tech debt is inevitable and is good as long as you keep the level of debt reasonable, so maintanance cost doesn't sunk too much of your dev time.

More good examples:

1\. Technology progress: Long time ago JQuery was the best for UI library. Today you would use React or friends.

2\. Company stage. As a early startup you usually prioritize for speed and validating hyphothesis. As you got a significant user base quality matters more.

3\. Size of development team. With 5 or less developers having a monolite is good enough. With 50 developers you likely take more advantage of microservice architecture so each team can be decoupled and move faster.

<comment><USER20> > With 50 developers you likely take more advantage of microservice > architecture so each team can be decoupled and move faster.

Microservices aren't magic. There still has to be a contract between the services. Microservices are best when they are something which need to be scaled independently of the rest of the system.

</comment></comment><comment><USER21> I prefer the definition of technical debt being an uncovered call option: at some point the debt will come due and you don't have anything in place to mitigate the issues it will cause and may not know when it will come due. This debt might look like a manual deploy process, a lack of automated testing, insufficient alerting, no rate limiting on public endpoints, etc. These are things that are fine and then when they're not, they interrupt the schedule and require urgent and immediate attention.

Bad architecture can cause urgent issues and it can also impact new feature development. The debt is a barrier that makes new features either take much longer than they should or make them just infeasible from a business standpoint. This can exist in both technical architecture or information architecture (i.e. you chose the wrong model and now it's too engrained across everything to change).

</comment><comment> munk-a Tech Debt is never good, but it can be acceptable in exchange for a greater gain.

So, just like this article's opening:

> Financial debt isn't universally reviled in the same way. Your friend takes > out a mortgage to buy a house and what do you say? Congratulations!

Except it is universally reviled, no one wants debt - they just accept debt in reasonable quantities as a way to efficiently get things done.

I think, in particular, the success of not-quite-agile-but-similar business practices has confirmed this, plan carefully and evaluate business needs, then get it done in a way that's fast and leaves you relatively free of debt - don't plan for everything. So don't get stuck in analysis paralysis trying to build the perfect things - and don't just code with no thought of the future... it's a difficult road to follow.

</comment><comment><USER22> I'm not sure if I'd even consider these things tech debt. I tend to distinguish between:

1\. Unfinished/unpolished implementations 2\. Implementations that are architectural flawed, such that fixing them requires throwing away the existing code.

Issues in (2) are a lot more problematic than issues in (1).

<comment><USER23> Yea, I was going to say the same thing. Work undone as part of prioritization is not debt. Debt to me is causing more work than it would take otherwise so that less work can be done now (or because the developer / architect just doesn't know any better). Using a switch statement instead of a factory. Using role based auth instead of attribute based. Things like that.

The problem is, the debt metaphor is not being applied correctly. Not doing future work now does not take on responsibility for the future work - so it's not like taking a loan. Doing work in a way that commits the team to extra work that didn't exist before - that's like taking on a loan. For instance, I don't want to do this 80 points of work now, so I'm going to ship the same requirement by doing 40 points of work on a solution that will take another 60 points to get to the original 80 point solution which is the way we know we have to go long term. I just borrowed 20 points on behalf of the team.

</comment></comment><comment><USER24> I'm not sure how this classifies as tech debt, but in my experience the worst type of tech debt is found in parts of a system that is relied upon and whose business logic has become unmaintainable, is too complex/poorly understood and is not possible to throw away as too many things depend on it. Also usually whose initial creator is long gone, the documentation is conflicting with the code implementation. This kind of debt causes eternal confusion and constantly lowers the productivity of the team. In cases like these, workarounds are created and more tech debt accrues on top of it that is even harder to reason about. Nobody sane can fix a mess like this and the only hope is death of the system or complete overhaul.

</comment><comment><USER25> Another kind of good tech debt I was hoping to see here is when something is built somewhat poorly/quickly because it will give you _information_ that you need to have in order to know whether it's worth building it any better.

<comment><USER26> Prototypes are very valuable as long as you know to throw them away and build the real thing. The unfortunate aspect of many business environments is that low knowledge outsiders see something "working" and demand that it be thrown into production for [insert business speak reasons]. Tech debt isn't always a decision made by the subject matter experts.

</comment></comment><comment><USER27> If you aren't spending tech debt, you don't have a sound monetary policy. Zero tech debt is not a healthy goal.

<comment><USER28> Unlike financial debt, which has a clear quantitative measure, Tech Debt is an incredibly fuzzy concept to the point of being useless for anything other than covering one's ass. We can do better as engineers than resting on such fuzzy thinking.

<comment><USER29> But that's the point. It is a fuzzy thing. Software is built on business priorities, not technical ones. These align a decent amount of the time. Spending the extra time and money to set up tests is very much worth it.

Is it worth implementing a cache layer in a system? One on hand, you have a better system that can handle more load, on the other, you've spent time that could be spent doing something else. Your systems will almost always have limitations, it's important to understand these and communicate them well. Tech debt should be managed so it doesn't tip over and cause issues. Really good devs and dev managers develop the eye to see when that's about to happen and make sure they convince product that you need to pay that down soon.

<comment><USER28> > Is it worth implementing a cache layer in a system?

This isn't a "Tech Debt" thing. This is a feature/scoping thing. Does my system need to handle 1M concurrent users? If so, support that. If not, don't support it.

But we don't need the absurd concept of "Tech Debt" for effective analysis. We can be specific. We can be clear. Does my system need to support low latency in the face of 1M concurrent users? Yes or no. Now proceed.

"Tech Debt" is such a ridiculous dodge to otherwise avoid real analysis, real work, real clarity.

<comment><USER12> I think it's pretty clear that there are often, clearly, no right answers to a lot of questions.

The answer to "Does my system need to handle 1M concurrent users?" could be "Yes", "No", "Not for the foreseeable future" or even "I don't know".

Given that 'debt' is a way to, in effect, allocate (possible) future resources today, it's pretty _clear_ why it's valuable, especially in the face of uncertainty.

<comment><USER28> What you're saying is no one has perfect forsight.

That's a given.

You don't need the notion of "Tech Debt" to deal with that.

It is a complete given at any given time, during any given sprint, that all the features in the queue are ASSUMPTIONS.

That's just a tautology.

"Does my system need to handle 1M concurrent users?"

Maybe you answer Yes or maybe you answer No, but you have to answer something to make decisions about the work ahead of you.

The worst possible place is to be in the fuzzy middle saying fuzzy things like Tech Debt and rolling along fuzzily.

Many teams -- especially teams that love this term "Tech Debt" \-- do exactly this.

But they are willfully navigating in the dark and "Tech Debt" is just a term that makes one feel psychologically okay with their ignorance.

But it's euphemism, that's all it is. It does not aid in rational navigation.

</comment></comment></comment></comment></comment></comment><comment><USER30> Nice article.

The code review articles are good too: [https://engineering.squarespace.com/blog/2019/code-review- cu...](https://engineering.squarespace.com/blog/2019/code-review-culture- part-1) [https://engineering.squarespace.com/blog/2019/code-review- cu...](https://engineering.squarespace.com/blog/2019/code-review-culture- part-2)

</comment><comment><USER31> I've always believed that "debt" is not a great term for this. Because it does not really apply to financial debt.

Financial debt is often repaid simply by bringing in more revenue because of the benefits gained from bringing on the initial debt. The only risk involved in the debt is that there will not be enough money to pay it back later. It is a very predictable and obvious issue.

Technical debt is closer to educated gambling. You are taking a risk that the shortcuts you are taking will not pop up and hurt your company before you fix them. You are essentially saying, "We know this is a problem, but we are estimating that it won't hurt us for the foreseeable future".

The better analogy to technical debt is investing. You are getting a certain percentage increase in productivity(a dividend or other capital gain) for the (hopefully low risk) gamble that your investment will not have a problem and wipe it out or simply cause significant losses.

Developers typically do not like this because when the inevitable few cases of these "investments" turn bad, they tend to be the ones that take on the majority of the blame.

<comment><USER32> To me they even sound the same after you explained them.

Not being able to pay back money sounds like the same as not being able to fix bugs.

</comment></comment><comment><USER33> Tech Debt, to me, grows with every line of code you write that didn't replace a line of code. Consider how many projects start with the idea, 'I'll rewrite this and get rid of the tech debt'.

First, If the original code isn't deleted, you've added to the tech debt. Now every new engineer will need to learn two chunks of code, and every existing engineer will need to support both.

Second, unless you've had a major epiphany between the old code and the new code, you're more likely to run into the trap of the first example. Major epiphany's could be, 'wow, we really didn't need all of that extra stuff', or, 'we've duplicated so much code, we should re-organize this all'.

I've been at plenty of companies where you have to understand that the Perl code is really old and these components use that, the Mason rewrite was 80% done and is over there, the Next Gen code was in Ruby these components do that. But now, we're embarking on a new Node/React project to replace all of it, finally going to get rid of the tech debt! (Said with no sarcasm)

<comment><USER34> If tech debt is inevitable, what's the solution? Good internal documentation and rewrites every few years?

<comment><USER35> a practice of constant refactoring..

</comment></comment></comment><comment><USER36> Nicely done. Good to see an engineering blog acknowledging tech debt openly.

I'm with you all the way until the last paragraph which short-changed the conversation a bit. Quoting a few lines to respond below:

>> Build things to be easy to throw away and replace; it'll make your code more modular.

One valid strategy to manage debt is to declare bankruptcy or amnesty on debt – that is throw away the code (because this code is no longer needed). In domains where this possible, definitely use it. But in most real-world touching software domains this is not likely possible.

>> Good tech debt has clear, well-known limitations. Document these in code comments, READMEs, FAQs, and conversations with the people who'd care.

Doing tech debt accounting in a more formal manner is required to intentionally take debt. In the locking example, it is a design debt (not just a code debt). If the debt isn't document well and then it can become a ticking time bomb to be tripped by a clueless developer later.

</comment><comment><USER37> The defining characteristic of technical debt is attempting to avoid paying it, taking shortcuts that create "interest" in the form of increased effort and cost; it's always bad, but depending on timing and costs it can range from a "correct" minimum cost choice (e.g. badly tested truly throwaway code) to a stupid mistake to an existential threat.

Technical debt is a close relative of externalization (I save time, you waste time) and of mistakes that result from incompetence rather than from haste and shortsightedness.

All three sections of the article, instead, describe healthy planned evolution from a decent provisional product to a better one, with solutions that might be rough but not necessarily bad. In other words, a clickbait title for sound (but maybe unrealistically mature) examples of properly pragmatic project and product planning.

</comment><comment><USER38> @1: One could also have automated tests instead of scaffolding.

@2: Sure, but this it not really technical debt. It is the wise policy of not immediately writing code for the most general case. If one writes several instances of this it would lead to code duplication that would need to be refactored immediately.

@3: Careful with this one. The thing is that the thing you call an edge case might have the more proper name of 'bug'. If you deliberately leave in bugs at the time of writing the code it can lead to very difficult to estimate 'stabilization time' at the point where the code is supposed to go into production but is not quite reliable enough. It becomes somewhat difficult to explain if that 'stabilization time' turns out to be months or even as much as a year.

</comment><comment><USER39> > Good Tech Debt Is Intentional

When it comes to accelerate development in my opinion this is most (80/20) of it.

</comment><comment><USER40> Love love love this article. I'm so tired of hearing lazy, unskilled, disorganized, mismanaged, etc. companies handwave the shit they write as simply being "tech debt". Sticking 50ms waits throughout your code, because you're not good enough to figure out how to actually trigger your action from an event or await something completing isn't "tech debt". Maybe hiring people not good enough to figure it out could be considered that from a higher level..

If we are going to allow the tech debt metaphor to continue, too much of the debt I see is the equivalent of a pay-day loan.

</comment><comment><USER41> I take a chance and say it right out: Fix some kind of image library functionality! As a customer who's also used Wordpress (everyone?) its just madness that I have to keep originals on disk somewhere to post it onto another page. I can hardly figure out how to download the full size original to be able to upload it again. I ask you humbly, please, you have the power to improve my life!

If you want me to stay on topic -- this is the worst wasted time debt Squarespace has to me as a customer :) code wise the product is really solid so their philosophy is obviously good!

</comment><comment><USER42> I think that "Good Tech Debt Is Intentional" is the key point. If you are able to recognize something as technical debt as it is created, you can also more effectively plan for paying it down later, and note what you think the solution would be at a high level. The real issue with tech debt is not that it exists, but that people wait too long to pay it down, and then end up taking more dependencies/making more technically bad decisions to deal with the tech debt which just makes it even harder to fix.

</comment><comment> another-dave "Financial debt isn't universally reviled in the same way. Your friend takes out a mortgage to buy a house and what do you say? Congratulations!"

There's an implicit assumption there that your friend can afford the purchase. If banks did no credit checks & your friends were impulsive & broke you might try to talk sense into them instead.

Maybe we need to store PM's technical debt for 10 years and perform a credit check when they say "I don't care, just ship it & we'll clean it up later"!

</comment><comment><USER43> > Financial debt isn't universally reviled in the same way. Your friend takes > out a mortgage to buy a house and what do you say? Congratulations!

We do say Congratulations! - we say well done on finishing the project you were working on.

I do agree with the part on not putting too much worth on edge cases, however the biggest issue for me with Technical Debt is the increased time it often leads to in further development. So I wouldn't say it's something to completely ignore.

</comment><comment><USER28> I'm going to take a more controversial position here, and it bothers me that it is even controversial.

The very concept of Tech Debt, though prevalent, is pernicious, because its a concept that is far, far, _far_ too fuzzy and therefore can -- and _is_ \-- always applied as a convenient narrative to explain away mistakes, process deficiencies, bugs, etc rather than a true conceptual problem-solving tool that aids in optimizing the software development process. In short, "Tech Debt" is a euphemism for incompetence.

We can see this play out in this post, which covers "3 kinds of good tech debt.

1) "Scaffolding" ... what the author describes here is good ol' fashion Prototyping, aka Learning. No invocation of a fuzzy concept like "Tech Debt" is needed here. You don't know something, so you go and learn what you need to learn. Learning takes many forms. In this case, it is product understanding -- and this author reaches for prototyping in particular and calls it Scaffolding. Why a new term? Why obfuscate, why fuzzify? Because that's what Tech Debt is good for: fuzzy thinking. If we move to more clarity we can be specific and we can take specific actions to optimize: here, maybe or maybe not prototyping isn't the most efficient way to learn what is needed: often, wireframes shown to customers will suffice. There are plenty of ways to skin this once the framing is clear.

2) "Hardcoding" Again, no fuzziness is needed here. Developers have a fetish for fully flexible and feature-rich subsystems and we tend to call anything else a pejorative like "hard-coding" but that's a psychological problem in us, not a technical or process problem. We already have a clear framework for talking about this and it's called feature Scoping. There are, again, plenty of ways to skin this cat, but the short of it is - if you can understand what features you are interested in with clarity then you can build a system whose flexibility is in accordance. This isn't a fuzzy "Tech Debt" thing. If you _only_ need feature X now and going forward, then build that - and call it something pejorative like "hard coding" if you want: I call it being rational. But bringing in a fuzzy term like "Tech Debt" helps nothing here. Only confuses.

3) "Not Fixing Edge Cases" This one is the worst of all. By using a fuzzy term like "Tech Debt" we're able to completely alleviate our responsibility. And start down a path of extreme cost and pain. Here, he wants to avoid having to implement correctness because it would cost too much. The example is a good one: it reflects a pattern I've seen over and over again. And unfortunately I've seen the same choice this author makes -- and the terrible downstream cost it creates, as well. By avoiding implementing a correct solution (by purposefully shipping a race condition) he is not being clever, he is being irresponsible. If this sounds draconian, let me explain further. Perhaps he finds, as he mentions, that in production this is inconsequential. Okay, great. But first thing to point out is that most likely it will become an issue as the system grows and when are you going to notice that? Are you going to go build monitoring to make sure that this "effective correctness" holds over time? Of course not, that's _more_ work. But even if you are happy with his choice here, there's a bigger issue. He has chosen to build a system with transactional needs on top of an eventually consistent/NoSQL solution. From my experience, it's rare that you have just one feature like his that needs transactional correctness and that is it. _Tomorrow_ , _next week_ , _soon_ \--he and his team are going to find out that they need another transactional capability and then they are going to be right back where they started: having to ask a question, do I slack off here, as well? Again -- we've created cost for ourselves by forcing us to ask, should I ship a bug in _this case_? One might say this is what "Tech Debt" lets you do! It lets kick the can down the road, save you some time now... But I do not buy it. I've seen this exact kind of choice made plenty of times and the can always comes back next week, next month and the tax you pay for not getting right is immense. "Tech Debt" here is simply letting us avoid responsibility, avoid having to understand the needs of our overall system. The cost of getting transactions right/correct is not even that high if you face it squarely and truly make sure you need NoSQL and in which cases. What's happening here is not clever process optimization but inexperience. And if not inexperience, laziness (not the good kind).

The concept of "Tech Debt" is awful. And always ends up being a euphemistic excuse. I've never seen the idea of "Tech Debt" help the actual process and technical quality of things. I've only ever seen it give developers an excuse for inexperience, laziness, etc. I don't mean to denigrate here -- I mean to challenge and ask for us to be more intentional, clear, and frank in our work. "Tech Debut" is fuzzy thinking and fuzzy thinking isn't much good for anything other than excuses.

<comment><USER36> I think you are being overly harsh. Since you seem to take issue with the term tech debt as a fuzzy term, I suggest you read up on the research on this matter (Researchers talks and paper published by [https://sei.cmu.edu](https://sei.cmu.edu) is a good starting point).

A developer aiming for technical supremacy for its own sake isn't useful in a real-world business scenario. I've seen enough technically superior software products utterly fail in the market due to poor product-market fit iteration speed.

Tech debt isn't a choice an individual developer should make. Tech leaders at the top of any evolving software based product/service should deeply understand the pros and cons of the concept of tech debt and then decide to use it as a strategy lever.

They will have to make appropriate choices w.r.t people and process that is right for their company to leverage tech debt.

This will reflect in the technical architecture of the systems as well. There will be different layers of the stack where tech debt can be more vs less.

There are automated measure that can keep you informed if the tech debt is exceeding to the point where it is becoming a net liability (vs being a net asset as a strategic lever).

It may be true that many organizations use the term tech debt very fuzzily and don't really give it conscious and serious thought and put effort to structurally leverage it. In this, your rage against may be justified.

For those who are interested to read more on tech debt should visit these links:

[https://martinfowler.com/bliki/DesignStaminaHypothesis.html](https://martinfowler.com/bliki/DesignStaminaHypothesis.html)

[https://martinfowler.com/bliki/TechnicalDebtQuadrant.html](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)

[https://2019.techdebtconf.org](https://2019.techdebtconf.org)

<comment><USER28> > Researchers talks and paper published by > [https://sei.cmu.edu](https://sei.cmu.edu) is a good starting point

Please link to a real paper that explores Technical Debt. This is just the link to SEI's home page. I'm looking for clarity, not hand waves.

> A developer aiming for technical supremacy for its own sake isn't useful in > a real-world business scenario.

You're straw-manning.

We're not looking for technical supremacy at all. (See my point #2 and my emphasis on brutal practicality.) We are looking for business optimization and all of the pragmatism that comes with that.

My objection is to using a dodgeball term like "Tech Debt", which in no way helps to carve a pragmatic path forward.

It is akin to hand-waving. If you move forward with any degree of efficiency, it will be in spite of your use of the fuzzy notion of "Tech Debt". You can do just as well without this (non-)concept.

I would call this "My Thesis" but that acts as if the burden on me is to justify my objection.

The burden is on whoever introduces this silly "Tech Debt" notion to 1) clarify what exactly it means and how to measure it; and 2) give a model in which the measurement can correlate with an improvement to the software process.

Otherwise you're just talking Santa Claus.

I have yet to see anything close to that kind of clarity when one discusses Tech Debt. There are a dime a dozen posts on "Tech Debt" and if you dig just a little you'll see that it is nearly always used to avoid clear analysis.

To be fair, clear analysis is hard, so I can understand why people give up and take the easy path. But let's call the spade a spade. "Tech Debt" is a dodge. It's not a constructive tool.

Your links are not helping your case either.

Fowler's writing explicitly makes a distinction between quadrants of Tech Debt and the only one he calls "Prudent" is the panic "We must ship now scenario."

If this is the only form of "good" Tech Debt, then my case rests completely.

Because all that is being said then is that "I literally have no idea what situation my code assets are in but I have to ship now, so let's go with whatever's on disk!"

Again, this is fair business. Anything is fair business.

But this is certainly a position of ignorance and not a position of strategic choice. So if can admit that "Tech Debt" is simply "Ignorance", then we are all in agreement.

Admitting ignorance, incidentally, is the only way an experienced practitioner can emerge and reduce the likelihood of being in such positions to begin with.

Matters are even worse. Besides "Tech Debt" being a useless concept. For the _individual_ it creates no clarity, no admission of deficiency, and no incentive or need for growth.

<comment><USER36> >> The burden is on whoever introduces this silly "Tech Debt" notion to 1) clarify what exactly it means and how to measure it; and 2) give a model in which the measurement can correlate with an improvement to the software process.

I would highly recommend this book: [https://www.oreilly.com/library/view/managing-technical- debt...](https://www.oreilly.com/library/view/managing-technical- debt/9780135646052/)

Also, read the papers presented at this conference series. [https://2019.techdebtconf.org/#program](https://2019.techdebtconf.org/#program)

<comment><USER28> Thanks for these links. I read through the book's examples of Tech Debt.

The book enumerates some examples of failed software projects and calls their failures "Tech Debt".

I have two issues with this.

The first is how fuzzy this still is. This term is thrown over all of these various kinds of failure. And the examples are also quite varied - most are phrased as mere symptoms of failure not root causes, which gives us little insight.

The bigger problem I have is that these examples are retrospective.

If Tech Debt is simply a term for "mistakes I have made", then by all means use it -- obviously in this form it has no strategic/constructive value.

But the way I've seen it typically used is for people to act as if it is akin to real debt, consciously acquired.

"Oh I didn't make this transactional because Tech Debt."

Etc.

And indeed if Tech Debt as a concept is to have any value it should be able to be used this way.

But my objection is that there is no way it can be used as such, because it is far too nebulous a concept to have any navigational benefit.

It gives no helpful path forward. It is purely a euphemism for mistakes. That's how I've seen it used universally, at least.

</comment></comment></comment></comment></comment><comment><USER44> JS-mandatory text-only blog posts are bad tech debt.

[https://outline.com/fH9GzD](https://outline.com/fH9GzD)

</comment><comment><USER45> Great article.

But the only reason their approach to the "11 item" edge case works is that they manage their own data. So they can monitor and might potentially cull manually if it became necessary (eg. What if the race condition caused more than 11 or a future codechange elsewhere stumbles on it).

In a non-cloud product where the cost is higher for a vendor to come verify and fix data, this wouldn't fly.

</comment><comment><USER46> _So we asked ourselves, "What's the simplest thing that would make the editor useful to our coworkers?"_

To me, technical debt is associated with a sense of regret. The example in the quote above doesn't have that, perhaps that is what makes it the good kind.

<comment><USER28> Perhaps this isn't "Tech Debt" at all. Perhaps this is a long understood, well-known activity called Prototyping or Learning. Perhaps the concept of "Tech Debt" is just fuzzy thinking.

<comment><USER46> Yes, something like that. When a suboptimal solution serves a strategic purpose it is not TD.

</comment></comment></comment><comment><USER47> I'm failing to see the point in calling a technical dept "good". As far as I can tell from the article, the author is measuring 2 possibilities of technical dept and choosing the one that incurs the least dept. I can see how good a decision this is but I don't see how this makes the dept good.

<comment><USER48> > I don't see how this makes the dept good

Time to market, for one. If you get the feature out faster to your customer, eating some debt can be worthwhile. This article is merely providing a structured way to think about the debt you're taking on.

</comment></comment><comment><USER49> This is a good take.

</comment><comment><USER50> > if now >= NEW_CONTENT_DATE

No canary? Tsk tsk.

</comment><comment><USER51> This was an amazing article.

</comment><comment><USER52> Sometimes going in a Hardcode way is much better than going around in circles to get the perfect code. Saves time and is more intuitive.

</comment><comment><USER53> No, and no, and no.

Just fix it. Repeat until completion.</comment>


Uber and airbnb. What could possibly go wrong? - <AUTHOR> https://www.linkedin.com/pulse/uber-airbnb-what-could-possibly-rob-norman

<comment><USER2> Some seriously excellent points</comment>


Fake ATM doesn't last long at Defcon - <AUTHOR> http://www.itworld.com/security/73295/fake-atm-doesnt-last-long-hacker-meet <comment><USER2> I'm surprised no one started taking it apart

<comment><USER3> Yeah, I was expecting a story of how the hackers had reverse-engineered the device and found details of the skimmers

</comment></comment><comment><USER4> It's particularly galling because the fake ATM was put _right outside the security entrance_. I'd almost be willing to bet that any account number/PIN tuples gained from this (if they were collected before the unit was discovered) won't be used. This was someone making a point, and they did an excellent job of it.

</comment><comment><USER5> I seriously doubt the "criminals" who did this didn't know Defcon was taking place. They most likely were attendees pulling a prank to make a point.

There's other similar shenanegans at Defcon, like the Wall of Sheep, which sniffs network traffic for unencrypted logins and displays them (with most of the password obscured) on a projector screen.

</comment><comment><USER6> How do the property managers not realize that someone has dropped off an ATM that isn't supposed to be there? Is it just me or does it seem like the properties are partially responsible if someone gets ripped off by this?

<comment><USER7> They're probably just as naive as I was (before reading the article) about the existence of fake ATMs set up by scammers. I don't think it's common knowledge that this happens, is it?

<comment><USER6> If someone set up a Coke machine that stole people's dollars, do you think they'd notice? This doesn't have anything to do with the scam, but simply being completely oblivious as to what's going on in your place of business.

<comment><USER8> I don't think the people at the front desk are aware of which contracts for vending machines or ATMs. They could have had 4 guys bring it in and make up a slick story about how they had a work order to install the machine and the front desk would probably not have the authority to act in any direction other than send the info up the chain.

</comment></comment></comment></comment><comment><USER9> Unfortunately, it now appears that there were other fake ATMs around, these at the Rio. These were not removed promptly. A friend of mine is out $200 and some of his friends are out more. Worse, no one can seem to figure out which law enforcement agency is responsible. See @chrispaget on twitter, e.g. <http://twitter.com/ChrisPaget/status/3100154939>

and following.

</comment><comment><USER10> When you walk in to Defcon you'd better be prepared at _every_ turn, that includes any equipment you interact with.

Imagine the scoop if they had gotten away with it cleanly. Everybody is concentrating on the latest wifi snooping hack meanwhile some joker walks off with the account info / pin numbers of half the attendees.

If the attendants of a security conference can be scammed like this it is really no surprise that it happens to the general public on a daily basis. I don't use any ATMs that are not 'wall mounted', always check the slot if it is securely attached and doesn't have extra reader heads.

And in spite of all that I still had a card cloned in a restaurant in Toronto... the bank was pretty good about it but it was still surprising to be so careful and still get cloned.

Pretty stupid of the person cloning the card to use it the same evening, that narrowed it down quite a bit.

</comment><comment><USER11> The day I use an ATM machine that isn't physically attached to my bank is the day I die.

You know, with the fees and all.

<comment><USER12> You probably drive across town looking for $0.01 cheaper gas, right? :-)

<comment><USER13> People are irrational: they are loss-averse; subject to endowment effects; randomly switch between social and economic valuations of their time.</comment></comment></comment>


IPv6 Ping Pong (2007) - <AUTHOR> http://www.potaroo.net/ispcol/2007-05/6pong.html

<comment><AUTHOR> Inspired by the conversation in [https://news.ycombinator.com/item?id=8514990](https://news.ycombinator.com/item?id=8514990) regarding Postel's "...be liberal in what you accept."</comment>