Autopilot: an open source driving agent - <AUTHOR> https://github.com/commaai/openpilot <comment><USER2> Not everything seems to be open source. I can't seem to find the vision part, only the binary, see: [https://github.com/commaai/openpilot/tree/master/selfdrive/v...](https://github.com/commaai/openpilot/tree/master/selfdrive/visiond)

<comment><USER3> Based on a really cursory inspection of the binary and symbols, the binary seems to be an OpenCV project which uses some common image processing algorithms (Sobel edge detection, Hough to find straight lines).

There doesn't seem to be a large amount of embedded data indicative of a trained model or neural network.

So, it seems that the vision algorithms probably mirror those in the common literature and represent a reimplementation or iterative improvement on existing lane-finding systems.

More reversing would probably yield greater insight :)

<comment><USER4> There's a neural network in there :)

<comment><USER3> Ha, straight from the horse's mouth - I stand corrected :) I think this will be the first binary I've pulled apart with one, look forward to it!

</comment></comment></comment></comment><comment><USER5> Actually the thingy is called "openpilot", there is already enough confusion with Tesla calling its thing "autopilot".

</comment><comment><USER6> This seems to be a code dump from the comma AI startup. It also indicates their autonomous driving platform runs on a "stripped version" of Android.

Which seems to indicate that they are clinically insane, given they are using a system that can easily have excessive scheduling latencies under load to steer a car.

<comment><USER7> People like me laughed at Android platform adherents because audio latency was a huge hurdle to even remotely be on par with Apple's Core Audio, but, believe it or not, 8 years later (give or take) Android has caught up. Point being, what might be "clinically insane" to you is simply a "fun challenge" to people who may be smarter than the both of us combined.

<comment><USER8> It's not about being clever with Android programming; it's about the fact that Android is not by any stretch of the imagination a real-time system and should absolutely not be controlling a car.

</comment></comment></comment><comment><USER9> This is great IMO. I was incredibly dismayed to hear they were canceling the Comma One without any further action, without even attempting to work with regulators. This seems like the culmination of that - now the responsibility for safety is in the hands of individual users/developers and not on Comma, which is what got them in trouble in the first place.

Now that this is open source though, I wonder what their next project will be?

</comment><comment><USER10> I have my reservations about this code. I am a long time free software developer so it is hard to say it but it seems clear to me that a single entity (from a legal perspective) has to "own" the self-driving car software.

In the future bits of a self-driving car system may get open-sourced the way Facebook Open Compute has emerged in data centers, but first the proprietary implementations will need to pave the way in the legal world.

It's not all bad news, though: I'd love to see a free software project that converted my lawn mower into a self-driving lawn mower...

<comment><USER11> > it seems clear to me that a single entity (from a legal perspective) has to > "own" the self-driving car software.

That's not clear to me _at all_. It seems clear to me that the person operating the vehicle has ultimate responsibility for how it is driven, whether they're personally driving it or not.

<comment><USER12> Interesting opinion. However, this isn't current U.S. law. See, for example, the numerous successful suits against Toyota for unintended acceleration.

In addition, it may soon be questionable to say that an occupant of a vehicle is "operating" said vehicle if it drives entirely autonomously.

</comment></comment></comment><comment><USER13> Interesting project, and valuable within the context of a larger autonomous system like the Robinos [0] autonomous vehicle framework from Elektrobit.

[0] [https://www.elektrobit.com/products/eb- robinos/](https://www.elektrobit.com/products/eb-robinos/)

</comment><comment><USER14> Really, a safety critical hard realtime system with control loops on top of Python, a general purpose OS and a CAN-USB adapter?

There are reasons why we have realtime operating systems, deterministic bus systems and dedicated CPUs for these kinds of applications.

That might be an interesting research, prototyping or simulation platform. But nothing you want to have on a real public road.

<comment><USER15> I'm not really following. If it _works_ then _why not_ use a control loop on top of Python? We are engineers, after all.

<comment><USER16> Because by "works" you mean "I tried it out a bunch of times and nothing bad happened, so must be production ready", because that's what you do when you build websites and desktop CRUD apps and nobody ever died cause the web server choked under load or the web page rendered a bit funny or the request took a full quarter second because the GC kicked off as a wave of requests came in.

And then one day a one-in-ten-million event that never would've surfaced during testing _does_ happen and the OS crashes or the interpreter hangs or some non-determinism causes a period of non-responsiveness or a bit gets mangled because you don't have any redundancies and solar rays are thing or ... and someone dies. And of course that didn't happen in testing, because all of those things are rare possibilities.

And then it happens again.

And again.

And then you're in court being sued for millions. And a bunch of industry experts who _do_ build their systems with redundancies and _do_ design their systems with a safety-first mindset come to the stand and rip you apart for not taking even the most basic precautions. And when it comes out just how many best practices you completely ignored, you're mostly just hoping beyond hope that all of the legal problems stay on the civil side of the civil/criminal divide.

Or, to say it in a sentence, "because the sort of exceptional circumstances that safety-critical software needs to handle with grace are very difficult or impossible to account for with a desktop machine running interpreted code on top of Linux."

<comment><USER15> I like that you reduced that to a one-liner, and I understand your point. I sure as hell wouldn't hook my car up to this software.

But I also feel like you're being a bit hasty. Obviously a Python script isn't going to turn into a Tesla overnight. But maybe it'll help you find a few bugs before you throw all that time and effort into building the real deal. When I look at a Github repo that claims to be a self-driving car I don't say to myself "yep, looks production ready," I say "Cool prototype, now let's break it." To me it seems entirely reasonable to get a working Python prototype 90% of the way there and then send it off to the OS programmers to design something that actually meets the concept of "production ready".

<comment><USER16> Yes, I absolutely agree with you on that. Nothing wrong with prototyping in whatever setting is most convenient.

I think w/ self-driving cars there is an interesting ethical question. The full auto cars on the roads today definitely aren't production ready, but they also have constant safety drivers. Probably even ACC systems are tested in the wild with a safety driver before production.

Basically, "is the safety driver sufficient to justify running prototype software in the real world?"

<comment><USER15> Yeah, that's a tough question that we as a society will have to wrestle with. Knowing that humans are imperfect drivers as well doesn't make it any easier. Even cars today have crippling safety flaws -- remember that one Lexus model that had a sticky gas pedal? Or worse yet, the Ford Pinto. I'm genuinely interested to see how the governments of the world weigh in on this, if at all.

Intuitively, though, I think that buying/using the software is tantamount to accepting its imperfections, so long as they are adequately (factually) presented to you beforehand. You're signing off your ability to make your own decisions, but are still responsible for them.

</comment></comment></comment></comment></comment></comment><comment><USER17> Is there a closed-simulation-environment to test this? By that I mean that the sensor inputs (images of the road, etcetera) are generated by the simulation environment with which the driving agent interacts.

<comment><USER18> Have you seen their Dash / chffr phone apps?

[https://itunes.apple.com/us/app/dash-train-self-driving- cars...](https://itunes.apple.com/us/app/dash-train-self-driving- cars/id1146683979?ls=1&mt=8)

[https://play.google.com/store/apps/details?id=ai.comma.chffr](https://play.google.com/store/apps/details?id=ai.comma.chffr)

</comment></comment><comment><USER7> So, ladies and gentlemen of Hacker News, following all the ire shoveled GEOHOT's way for closing up his project, can you please show me any equivalent Open Source contribution from major manufacturers that is comparable? Not like White Paper bullshit. I mean where has Tesla, Audi, or GM shared this kind of platform without Sam Altman writing a think-piece about how they're not as good as Cruise and he knows the truth and doesn't need to listen to fuckin' lawyers.

Sorry, maybe that was an inappropriate aside but I know I'm loud & proud team GEOHOT and have yet to see the Giants in the industry really show they can fend off a determined Goliath.

</comment><comment><USER19> His latest video [https://www.youtube.com/watch?v=vU26Pa6ERkY](https://www.youtube.com/watch?v=vU26Pa6ERkY)

</comment><comment><USER20> Curious why this isn't using PEP8? Another Xoogler?

</comment><comment><USER21> Correct me if I'm wrong, but if I were actually to install this in my car, that car would no longer be street legal, right?

<comment><USER22> The car would likely still be street legal. (IANAL) However, allowing this system to take control of your car on a public road would not.

Another way to say this is, there's nothing dangerous about the hardware. You could be using it as a logging platform for the data on the CAN bus in your car. But letting the software send commands and take control from a driver is a different story.

<comment><USER23> > The car would likely still be street legal. (IANAL) However, allowing this > system to take control of your car on a public road would not.

IAANAL, but I don't think even that is true. I think it actually is legal to allow it to take control of your car, provided you are still sitting in the driver's seat and can take control back at any time.

<comment><USER21> > can take control back at any time

but if you're going down the highway and the AI decides to suddenly swing the wheel far right as quickly as possible, no human being would have reaction time good enough to recover without crashing. I'd be pretty concerned if you could add an autopilot to your car and drive it around on public roads without any sort of demonstration of safety.

<comment><USER24> People are allowed to work on their own cars, including brakes, suspension, steering, etc. Happens every day in driveways everywhere. I do it myself.

<comment><USER21> But there are restrictions of what parts you can use. I can't just make my own engine and drive around with it without getting that engine certified, right?

<comment><USER24> I don't know of any reason why not. Certified by who? Who would ever know?

I can put a Chevy engine in a Ford, and plenty of people do much more than that, e.g. homebrew EVs, etc.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> Can this be good for other applications, ie drones or RC cars ?

</comment><comment><USER26> Hmm, the usage of .dbc files is interesting. That format is owned by Vector and proprietary. I'm curious as to what the limits of using DBC are, as I'd love to integrate them into the product I currently work on without paying thousands of dollars for the official API from Vector.

</comment><comment><USER27> Why is the zipfile encrypted?

</comment><comment><USER28> Awesome! not sure about using it my real car, but I'd stick that on an RC car if it works.

wondering whether this can run on raspberryPi...

</comment><comment><USER29> You want me to trust my life with a source code that uses zmq? no thanks.

</comment><comment><USER30> George Hotz once said[1], if Tesla Autopilot is the iOS, Comma.ai's system is the Android. Today he's the MAN of his words by open sourcing Comma.ai openpilot.

Big kudos to Geohot!

[1]: [http://learnbonds.com/131150/tesla-ios-self-driving-comma- ai...](http://learnbonds.com/131150/tesla-ios-self-driving-comma-ai-android/)

</comment><comment><USER31> I read an interesting ethical dilemma related to self-driving cars recently.

Imagine that a self-driving car detects a child in the road, and the only way to avoid hitting the child is to crash the car in to a wall, certainly killing the driver.

What choice should the car be programmed to make?

Who should decide what that choice is?

Who is ethically responsible for that choice?

In a normal car that is driven by a human, the choice is obviously made by that human and the responsibility is theirs. But with self-driving cars it's not so clear.

<comment><USER32> Other threads related to autopilot (mainly Tesla), with great posts that explained in detail why this problem is unlikely to arise in reality and that the resultant action undertaken by the system would be the same in both scenarios (e.g. apply brakes as hard as possible).

IIRC part of the explanation was that a human is unlikely to make a qualified choice in a situation like this anyway, so programming a decision matrix based on the utility of the target into the crash avoidance mechanism is moot. Something like 99.999% of the safety benefit would be achieved by a faster brake response time.

<comment><USER33> It's also pointless to worry about because the proposed dilemma greatly overestimates the ability of computer vision systems to determine what an object actually is.

These systems are looking for obstacles and road contours. They don't know that the obstruction in the road is a human baby, let alone the composition of an adjacent wall.</comment></comment></comment>


Web Real-Time Communication [Video over WebSockets] - <AUTHOR> https://labs.ericsson.com/apis/web-real-time-communication

<comment><AUTHOR> Ericsson has implemented p2p binary websockets in Webkit, they have an implementation for Ubuntu that you can download and try.

<comment><USER2> It actually doesn't use WebSockets, media is sent browser-to-browser over UDP. This has the benefit of low latency.

<comment><AUTHOR> I did not know this! Thanks for the clarification.

</comment></comment></comment><comment><USER2> We are looking in to 64-bit

</comment><comment><USER3> 64-bit, where?</comment>


Dell's 43-inch 4K multi-client monitor is amazing - <AUTHOR> http://www.theverge.com/circuitbreaker/2016/5/20/11720778/dells-43-inch-4k-multi-client-monitor-amazing <comment><USER2> $1349 is not totally nuts, 2560x1600 displays requiring dual link DVI appeared at the same price point in mid 2007.</comment>


Could McDonald's Really Beat Starbucks? - <AUTHOR> http://business.theatlantic.com/2009/06/could_mcdonalds_really_beat_starbucks.php <comment><USER2> A pox on both their houses.

Seriously, I wonder how much of this is just simply due to the fact that McDonalds are much more likely to have a drive-through than Starbucks (at least that is the case in my state). I presume a lot of the profits come from the morning coffee-rush where time is at a premium, so I can see people stopping at McD so that they don't have to mess about with parking etc.

</comment><comment><USER3> This is one submission where the reader comments are better than the original article.

</comment><comment><USER4> I go to starbucks to get away from my normal work environment to work on projects or with a friend to sit and just talk about stuff. I can't see myself doing either of those things at a mickey d's

<comment><USER5> Interesting.

From my experience, a McD's is just about as noisy as a Starbucks on an average day. If I want to work on projects, I generally aim more for the local, less-commercialized coffee houses.

Is there an ambiance factor to this, or is it more of a psychological distinction between fast food places and coffee houses in general? Or is there something else?

<comment><USER4> Honestly, I like local coffee places much more than all of the above as well. But the thing I appreciate about Starbucks is that 1) they are all at the same level of cleanliness and relative comfort no matter which Bucks you end up at and 2) the crowd in them is usually there for the same reasons.

I tend to always work with headphones in so the noise isn't an issue.

I guess if I found a comfortable McD's with wifi I might have to try it out for a session :-)

</comment></comment></comment><comment><USER6> I don't know about you, but I personally think McDonald's mocha tastes like ass.</comment>


Google Chrome now has its own share button. Pushback please? - <AUTHOR> http://www.snipandshare.com/

<comment><USER2> This headline is awful. It implies the linked article describes a feature Google has built into Chrome. Instead it's a "Show HN" to be used within Chrome. Please correct. This sours me immediately on SnipAndShare.

<comment><AUTHOR> I am new to HN so was not aware of the unsaid rules. No mislead intended. But can't see a way to edit now. Will create a new one.

</comment></comment><comment><USER3> Did you mean feedback? :)

I don't use Chrome but this does look pretty slick!

<comment><AUTHOR> Pushback or encouraging feedback. Either. I believe sharing could be dead easy and Chrome is just a starting platform. Thanks!</comment></comment>


Mod_rails teaser video.  Are they pulling our leg or is it real? - <AUTHOR> http://www.modrails.com/

<comment><USER2> We can assure you that this is for real. We at Phusion have been working at this for quite some time now, and several of our beta testers include Rails core team members, as well as some of the largest RoR hosts on this planet ;-). And so far, the feedback has been overwhelmingly positive and we can't wait to share this with you guys. We do ask for your patience though, albeit for just a little longer.

Regarding documentation, we think you'll be more than pleased to see that we've gone the extra mile on this part. If anything, we hate bad documentation as well, so we really intended on tackling this with Passenger ;-). For more information regarding Passenger, be sure to keep a close eye out on <http://phusion.nl>, <http://www.modrails.com>, <http://izumi.plan99.net/blog> and <http://ninh.nl> as we'll be posting more about it the following few days/weeks.

Kind regards, Hongli Lai Ninh Bui \- phusion.nl

</comment><comment><USER3> I wouldn't get too excited without seeing some sort of actual documentation. Hopefully this is done ala-WSGI

</comment><comment><USER4> On a random note, this is a _really_ nice looking site design.</comment>


Ask HN: Review My Weekend Project, MagicalMoFo: Startup Coverage Syndicated - <AUTHOR>

http://magicalmofo.com
Hi HN.  I came across this post on HN, http://blog.traindom.com/places-where-to-submit-your-startup-for-coverage/, detailing where to submit your startup for coverage, mentions, and backlinks.  It was somewhat effective -- received over 50 reviews, mentions, tweets, and backlinks, got a few hundred visitors, and a handful of people signed up.  But it took 3-4 hours, mostly because it was really boring. Copy, paste, copy, paste, etc etc.
I wanted to make it easy for early startups to get this basic web coverage, and that resulted in Magical MoFo.  You fill in all the fields that these review sites require just once, and Magical MoFo will syndicate you out to 20+ sites.
I'd love to hear your thoughts, especially whether this would be of use and what you think of the price point.  Thanks! <comment><USER2> Gotta love the co-founder reviewing the service as a happy customer:

 _I have been very pleased with my own work. I syndicated my startup by hand and got over 50 reviews, mentions, tweets, and backlinks. I got a few hundred visitors and a handful of signups. But it took me awhile and it was godawful boring. I wish I had met the Magical MoFo earlier! My fingers would be less withered and my hair less grey._

<comment><AUTHOR> The other option I considered was syndicating MagicalMoFo itself to a bunch of those sites, using MagicalMoFo, then using their reviews as social proof back on MagicalMoFo.

</comment></comment><comment><USER3> It's a nice idea. Perhaps though, you could have a listing of startups who have used your service. For example, the other day I was looking to see if there's any new startups in my city (I'm in New Zealand). Sadly, I couldn't find much, nor for the rest of the country.

<comment><AUTHOR> thanks, veb! unfortunately, we've only had a couple of paid customers. but perhaps the social proof issue is the most glaring so i'll work on that. if you submit your startup, and i do a good job, you could write great things about me and i'll put it on the site.

</comment></comment><comment><AUTHOR> clickable: <http://www.magicalmofo.com>

</comment><comment><USER4> what is the full form of MoFo? I know of only one and that doesn't seem applicable here

<comment><AUTHOR> It's "motherfucker," but said in a joyous way. The name was inspired by a David Blaine documentary marathon. After blowing getting his mind blown a magic trick, some dude called David Blaine a "magical motherfucker."</comment></comment>


Shit Hackers Say - <AUTHOR> https://www.youtube.com/watch?v=ETYHvOOx5BY

<comment><USER2> As someone who has been to way too many hackathons, this video resonates with me so much that it's depressing.</comment>


Ask HN: Balsamiq vs. Invision vs. Justinmind vs. Axure vs. XD? - <AUTHOR> I'm looking to learn a new frontend prototyping or wireframing product. Some on my "short list" are:<p>- balsamiq
 - axure
 - adobe xd
 - justinmind
 - invision
 - figma<p>What are your favorites for single-man or small-team projects? What should I know about each from your experience? I'm fairly certain I'll be using it for a React webpage and complementary React Native apps for iOS and Android. <comment><USER2> From that list, I've used balsamiq, XD and Figma. Balsamiq is good if you want to convey the big picture design layout without design details. I used it for a long time with significant success. XD lets you get detailed. XD is remarkably simple in terms of the primitives you work with but you can achieve arbitrary design fidelity. Figma is best for collaborative design. However, I for one haven't had much success with multiple people tweaking a design. And I found the in browser interaction a bit flimsy.

These days I use XD exclusively. Sketch is a worthy alternative to XD that is probably cheaper if you don't have a need for other tools in the Adobe suite.

</comment><comment><AUTHOR> # of job postings mentioning each brand on Indeed.com:

Justinmind - 6 Balsamiq - 327 Axure - 602 Figma - 635 XD - 686 Invision - 1717</comment>


Ask HN: Do startups still focus on obtaining patents nowadays (2017)? - <AUTHOR> Cost of the fees can be $10k+. Typically one has no $$$ to actually execute and enforce a patent. It looks like to have a startup with IP protected by some legal paper, but realistically it's useless. Do patents even increase the valuation?<p>In other words: is it still worth to bother about thinking about patenting in a startup? <comment><USER2> They never did.

If you use the definition of a startup as "still searching for a business model" and not "any company of any age and size as long as it's involved in technology", then there's no reason for them to apply for a patent.

By the above definition, startups haven't yet figured out what is their exact product, what is their business model etc. There's nothing there to protect with patents yet.

And what also follows, they're not successful yet so no-one will sue them for patent infringement. Lawsuits are about money. If there's no money to extract, there's no point in suing.

</comment><comment><USER3> Old world companies usually/commonly avoided patents, as they just spelt things out for the competition (ie, showed the competition how to copy them). Most things worth knowing were held as trade secrets.

Having a patent could easily be a good marketing strategy, but I'm not sure if it's as relevant today (I'm saying I don't know not that it isn't relevant).</comment>


How do most SPAs handle breaking API schema changes? - <AUTHOR> https://twitter.com/garybernhardt/status/1140714850860933120 <comment><USER2> I use grpc-web and protocol buffers.

Renaming fields doesn't matter -- if the client and server disagree about the name of a key, it doesn't matter, because the transport layer uses the tag number, not the name. (Compare this to JSON, where changing the name does break clients.)

Adding fields also doesn't matter, but this is where it starts to get tricky. If a client sends a request without a field that the server expects (i.e., an old version of the client), the message will parse OK, but the server could still say "hey actually that's required, buh bye". If you do this, you lose the backwards compatibility. So don't do that.

Removing fields is something you can basically never do if you want compatibility. You can rename them to deprecated_whatever, though, and see what code still uses them by the fact that they no longer compile. (Binaries using that field can still exist and will continue to work, of course. But at least you can have a transition period where people writing new code will think "hmm, this is probably going away" and won't depend on that field.)

(There are also some additional mechanical details that the protocol buffer documentation talks about. Maybe an int32 isn't big enough so you want an int64. Old clients can still talk to a server that has changed the type of an int32 field to an int64, but eventually it's going to lose data because it didn't allocate enough storage to manipulate an actual 64-bit value. But it does give you time when you think "a year from now this will be bigger than 2^32". You can change the definition today and eventually update all the clients.)

I think with care and the occasional update of a client, though, you can pretty easily keep things compatible forever. This is wayyyyy easier with SPAs than any other sort of API consumer, because you have control over updating the client.

Often you are adding new features, which is the easiest case. You add a new field or RPC, and just start using it.

You can usually structure a change in semantics as a new feature, which makes the cases for which protobuffers excel even more common in practice. For example, say you have clients that depend on the ordering of results from a Lookup() call. You think that that sort is unnecessary and slow, and you want to change the semantics without breaking clients that depend on the ordering. You can just add a new RPC, FastLookup(), and start using that. Clients that use the new RPC will be faster, but old clients will continue to work using the old method. You can update all those (check your monitoring, you probably have a grpc_server_handled_total metric for every method), and after everything's updated, you can safely remove the code that implements Lookup() (either delete it entirely, or to really do it right, return codes.Unimplemented).

I think if you aim for incremental progress, it's pretty easy to achieve with the right tools. It's harder, but possible, even for public APIs where you can't update the client. But where you can update the client and all you have to worry about is browser cache? Easiest possible case ;)

<comment><USER3> You can also remove a field by reserving the tag number and optionally the name. New binaries will fail to compile but previously persisted values can still be read back by old binaries. Also ensures no one uses the same tag number later and reads bad data.

</comment></comment><comment><USER4> Ideally, version your APIs, though for some internal APIs you definitely want to be able to make changes without bumping versions constantly.

Be backwards and forward compatible as much as possible. Rolling deployments and other factors virtually guarantee mismatched versions in both directions. Many things, like adding new fields or removing old ones, can be staged in such a way that nothing breaks. Protobuf/gRPC offers some form of backwards and forwards compatibility (at the data model layer, of course,) if you adhere to certain basic invariants.

Almost any change can be staged over time, how long you want to keep compatibility between versions is up to you.

Oh, probably most important: keep clear data model separations wherever you can. Between storage and API, and API and in-memory state management. It's a lot of work, but it pays dividends.

<comment><USER5> Not sure if this is standard, but what I usually do is bump the version only on a breaking change. So if I add a field, nothing new happens. Remove a field, or fundumentally change the output, then I bump it up.

<comment><USER6> Would you care how often you make breaking changes on your API if you control the client and it's your only consumer?

<comment><USER7> Yes, if especially if "you" is a company or engineering department. It can be difficult trying to figure out how to best deprecate a micro-service endpoint if you aren't quite sure what other services are using it and if logging is lacking.

</comment></comment></comment></comment><comment><USER8> > A number of responses say "have the client detect that it's running an old > version and force reload." That works, but it's pretty annoying UX.

Is it though? Of all reasons to force refresh, this sounds reasonable to me as it won't even happen that often.

Heck, I would _want_ to refresh if I knew a new version was available.

<comment><USER9>
      Is it though?

Depends if you're triggering it six times a year or six times a day. Some companies pride themselves on how often they deploy code to production [1].

And whether your SPA is something like Google Docs where a user could plausibly have the same document open for a week or more.

[1] [https://blog.newrelic.com/technology/data-culture-survey- res...](https://blog.newrelic.com/technology/data-culture-survey-results- faster-deployment/)

<comment><USER10> Is it common to be releasing breaking API schema changes 6 times a day?

<comment><USER11> Intentionally? Probably not.

</comment></comment></comment></comment><comment><USER12> The simplest answer is "don't make breaking API schema changes".

For a more complete answer, this is a great blog post from someone at Stripe about API versioning: [https://stripe.com/en-ca/blog/api- versioning](https://stripe.com/en-ca/blog/api-versioning)

</comment><comment><USER13> When you need to make a backward incompatible change, do it in three steps:

1\. Add new stuff to API in a backwards compatible manner (without removing or changing old stuff). When you need to add fields it is usually safe to do it within existing functions. When you need to modify fields, I recommend simply copying and pasting your API function and exposing the new one with a number suffix, e.g. get_messages_2

2\. Update the client code to use new versions of functions and to stop using old versions.

3\. Once the new client is deployed, wait a while longer and then remove old versions of functions like get_messages_1

You can also use a single global version which will allow your client to detect when it has gone stale and reload.

</comment><comment><USER14> What does this have to do with SPAs specifically? Any of the usual suspects for versioning APIs (URL paths, headers, etc) should suffice, right? The SPA is just another client.

<comment><USER15> SPAs as opposed to mostly-static web pages. I think all "rich clients" are implicitly included, although the "refresh" story does change for native ones.

</comment></comment><comment><USER16> We use API versioning. Works like a charm! If you don't currently have API versioning, just put the breaking changes behind /v2/<endpoint> and start versioning.

<comment><USER17> I guess the hard thing is that you lose versioning granularity at that level. If you made a mistake with your v2 rollout and the fix is breaking, do you bump to v3 or append the correct field? Do you leave the bug in the response still so that users can decide to depend on it? You can't delete. What would the user thing about bumping from v3 to v12 in a really short amount of time as the API is in flux?

Stripe's date versioning is the best implementation I've seen yet. The worst I've seen is using custom MIME types. Version number in the URL is naive but intuitive.

<comment><USER16> I've never come across your scenario. I would say if you need to fix v2 with a breaking change, then v2 must be broken to begin with. All that being said, going to v3 is not a problem either. I have a few APIs where we went up to v7 after 2 years of operation without issues.

</comment></comment></comment><comment><USER18> I don't know if most SPA frameworks offer this sort of functionality, but with intercooler.js you can send response headers to trigger client-side events (or, if you are feeling hacky, to evaluate raw javascript.)

This can be used to trigger a full browser refresh when the application topology had changed dramatically.

</comment><comment><USER19> How do you even handle SPA updates themselves? Apps may reference static resources (JavaScript, CSS, images) which get updated with a new version. Those resources could be clobbered by a deploy, or be uglified, or be versioned. Do you keep the old static resources in place forever, or for a period of time? Or force a reload? Or do you just let clients break and make users reload?

<comment><USER2> Yeah, the tooling around this is pretty bad. For example, you might release a container that has index.html and main.abc1234.js. index.html has to be parsed before the JS bundle is requested. If you do a release in that intermediate time, the javascript will 404 and your site won't load because in the new container, the only bundle that exists is main.def2345.js.

I think people additionally assume this never happens, because their error reporting code lives in the javascript bundle and they never get error reports ;)

The correct solution is probably to keep a few old versions of the Javascript bundle around, so that in-flight requests succeed even as you update the container hosting the app. I do not know of a tool that does this, but the edge case I describe above worries me, so I might write one someday.

<comment><USER20> Edge caching is a solution.

<comment><USER2> Yeah, I think that's a reasonable solution. It doesn't guarantee 100% accuracy, but it increases the chance that something will load.

</comment></comment></comment></comment><comment><USER21> This doesn't magically cure everything, but switching from REST to GraphQL can help make a lot of versioning-type issues disappear.

<comment><USER22> absolutely true in my experience also

</comment></comment><comment><USER22> graphql</comment>


Ask HN: Suggest Me a Language for This - <AUTHOR> - runs on linux - have green threads or fibers or... - talk to http, json, xml, redis - low memory & fast<p>I'm thinking crystal. Any other ideas? <comment><USER2> Erlang.

</comment><comment><USER3> Go</comment>


Ask HN: I have a mental block designing software. Time to quit? - <AUTHOR> This is embarrassing to admit after 15 years building web applications, but every project I hit a brick wall decomposing software.
I know the data inputs; I know the outputs. My prototype works. But my mind freezes when I try to rewrite the prototype into something maintainable that will run for 5+ years.
High level planning is fine, it's getting from what needs to happen to how to decompose into classes/methods/libraries, dependencies (logging everywhere) and organise message passing.
My current project is choreographing 3 enterprise systems to work together. Once past the lack of documentation it's conceptually simple; my code however is tangled.
Related, I have a mental block with drawing flow-charts. I can't isolate tasks, decisions, actions. The chart becomes spaghetti, or too detailed/too sparse to be useful. This is difficult when people want the system described on paper.
Either:
1) I need to learn something 2) It is an innate mental block, and I need to change fields
If I'm going to continue in software this needs to change, as I don't feel I'm delivering quality. The more senior I get the less I can stick with prototyping or "Just Works" as an outcome. <comment><USER2> What you're describing to me is you've built a very solid structure for reasoning about programs, but it is too rigid, and too focused.

I would _heartily_ recommend learning a new language. You need to shake things up a bit.

Two reasons:

1\. [https://www.wikiwand.com/en/Linguistic_relativity](https://www.wikiwand.com/en/Linguistic_relativity) \- Our language shapes our thought. This is true for spoken and programming languages.

2\. You cannot properly understand a language unless you learn another. This is partially based on point 1, but it needs to be said otherwise.

Since you're in web, I would recommend learning Elm for the front-end, and Haskell in the back-end. Why? They will force you to design your systems differently? Is it better or worse? That's subjective. The important thing is that it is different.

For data design, have a look at things like datalog. Datomic is a good playground for that.

<comment><AUTHOR> > I would heartily recommend learning a new language.

I've installed a nice selection of languages tonight. Can anyone suggest sample projects to do as learning exercises? My ideas a) don't need the language, b) are too complex or c) involve CRUD, and I do far too much of that every day :)

TIA!

<comment><USER3> Read "Functional Programming in Scala" or any other good book on functional programming to see things differently if you've just stuck with imperative so far. There's also [http://iloveponies.github.io/120-hour-epic-sax- marathon/](http://iloveponies.github.io/120-hour-epic-sax-marathon/)

Read books on concurrency ("Learning Concurrent Programming in Scala" if you carry on with scala) and then you'll find different ways to write performant concurrent code - for CRUD sites or other stuff.

I'm not pushing scala rather exposure to other ways of doing things you might not have come across - functional programming, futures, akka, etc.

But yeah, also design patterns. And have you read [http://highscalability.com/](http://highscalability.com/) for architecture ideas?

<comment><AUTHOR> Thanks for your comment!

> But yeah, also design patterns. And have you read > [http://highscalability.com/](http://highscalability.com/) for architecture > ideas?

Lots. I would love to have clients in that league (I greatly enjoy scaling, optimization, performance tuning)

</comment></comment></comment></comment><comment><USER4> I'm going to take a wild guess and say you don't really care that much about the purpose of your software. You're not a game developer who's been an avid gamer since age 4, or a silicon valley entrepreneur who truly believes their web app is going to change the world. You've identified a niche that's liable to make some money, and are diligently plugging away at an implementation.

Your lack of inherent motivation from the product domain means you don't get any satisfaction from just getting the requirements met, so you hunger for the satisfaction of making a beautiful architecture. But all architectures have flaws. As a competent engineer, you notice the flaws in whatever you design, so your only source of satisfaction is compromised.

I would try to find work on a problem that excites you. When you get that giddy rush just from seeing your program give a correct answer. I think most software developers have felt this way about some project during their learning process. Look back and try to remember where it happened for you.

You're in trouble if software craftsmanship is your _only_ source of motivation. It's a great motivator, but it is not enough by itself to carry you through a big project.

Now that you're in this project, it may be impossible to quit. I would find a side project to work on that provides more satisfaction. That should make it easier to plug-n-chug away at your current project without becoming depressed at the inevitable small failures in elegance and design.

I've never understood how developers can be happy writing CRUD apps or wiring together a bunch of pieces made by someone else. You gotta search for meaning. Even if you take a pay cut, it's worth it to find work that you care about.

<comment><AUTHOR> > I'm going to take a wild guess and say you don't really care that much about > the purpose of your software. You're not a game developer who's been an avid > games since age 4, or a silicon valley entrepreneur who truly believes their > web app is going to change the world. You've identified a niche that's > liable to make some money, and are diligently plugging away at an > implementation.

Spot on. I walked into this career by accident, the money was good and I stayed. No, I don't know what I actually want to do - something I've never known :)

> You're in trouble if software craftsmanship is your only source of > motivation.

Spot on again. Pride in what I do is my only motivation at this point. I don't get to see happy users, find out how I've improved lives, get user feedback and _make things better_ for someone.

> Now that you're in this project, it may be impossible to quit.

It was impossible to turn down, as they're a good client and provide somewhat interesting work (always unusual tasks). Otherwise I wouldn't have touched it.

> I've never understood how developers can be happy writing CRUD apps or > pushing ads. You gotta search for meaning. Even if you take a pay cut, it's > worth it to find work that you care about.

CRUD is the most soul-destroying code to write as doing it with good craftsmanship is impossible (there I said it). Concerns overlap between the front and backend. I do share your sentiment, but pay cuts are hard (I suspect I undercharge at the moment, making them harder still).

Thanks for commenting!

<comment><USER5> Try your hand at Game programming, its great to mix things up and the communities are great:

Unreal Engine 4: [https://www.unrealengine.com](https://www.unrealengine.com)

Maybe a mod for Unreal Tournament or Ark Survival: [https://www.unrealtournament.com/blog/](https://www.unrealtournament.com/blog/)

[http://www.polygon.com/2015/8/14/9153379/ark-survival- evolve...](http://www.polygon.com/2015/8/14/9153379/ark-survival-evolved- hunger-games-mod-contest-survival-of-the-fittest)

Unity: [http://unity3d.com/](http://unity3d.com/)

Construct2: [https://www.scirra.com/](https://www.scirra.com/)

</comment></comment></comment><comment><USER6> Learning something is always helpful in some ways but it may not be exactly what you need. It sounds like you may be at a point in your career where you may be suffering some imposter syndrome when it comes to making the decisions to move the PoC code to something more final. I hit a stage as well, years ago where I was paralyzed by the 40 different ways to architect a Java web app and all the arcane crap that came along with it. In general patterns only serve to better understand and maintain your code. That should be your primary goal during this time, is this readable and maintainable? After that, think about ways you can make it more slick. Eventually, you get over the hump and those patterns become part of your writing style and you don't even think about it anymore, until you hear about some new cool pattern (MVC became THE THING during my professional time) and you figure out how to incorporate it. After this similar block I had in my career I never really had another, until...

I had a different type of block earlier this year. For the first time in my career (I'm 32) I left my employer to work 100% for myself. I spent the first six weeks so twisted up I'd go days without a line of code written- luckily there was enough in the way of infrastructure and Ops tasks to give me something to do. I think the stress of it all just kept me from being able to focus like I need to in order to develop.

I started taking breakfast with the wife and kids, going to the gym every single morning, walking around for at least 15 minutes at lunch, being home by 4:30 (instead of 6:30/7). I basically focused on everything else and after a week or two it just started coming back and I feel like I'm faster and less stressed than I've ever been. Even if I'm not I'm happier and my family is significantly better than before, so I'd do it again in a heartbeat.

<comment><AUTHOR> > It sounds like you may be at a point in your career where you may be > suffering some imposter syndrome when it comes to making the decisions to > move the PoC code to something more final.

Definitely! I'm the imposter that imposter syndrome was defined around ;)

> That should be your primary goal during this time, is this readable and > maintainable?

Oh, that's an interesting twist. Move the focus away from craftmanship of the present-day to future-proofing. It may be more ugly but if I can fix/extend it in 12 months without missing a beat then my job is better done.

> I spent the first six weeks so twisted up I'd go days without a line of code > written- luckily there was enough in the way of infrastructure and Ops tasks > to give me something to do. I think the stress of it all just kept me from > being able to focus like I need to in order to develop.

I'm 31 and that's how I've spent a lot of time recently. Especially when not working flat-out on a project to meet a deadline. Give me one of those and I'm happy: head down, pounding it out.

</comment></comment><comment><USER7> Sounds like a challenge on synthesis and perhaps design problems. I suggest you to not do anything drastic but use a pair of fresh eyes on your project. Manage to pair with someone and observe what this new guy finds challenging. You have to be open to refactorings or code style improvements. Also the guys must have to be good otherwise it could misguide you. What about using 3 instead of one? if they don't know each other you know the biases are under some control. After getting that quality feedback, you can ask yourself those questions again. You'll know better

<comment><AUTHOR> Good advice & I'd like to, my challenge is I work freelance/direct and don't have other programmers around to ask.

I think paying for code reviews and some mentoring is the only way I can get this feedback.

<comment><USER8> Why pay for review though? If you're working on open-source stuff you can try [http://codereview.stackexchange.com/](http://codereview.stackexchange.com/) for help, or reach out to some trustworthy people in your network as a fresh pair of eyes.

<comment><USER9> > My current project is choreographing 3 enterprise systems to work together

Well, don't think that's going to be open source.

</comment></comment></comment></comment><comment><USER10> Time to take a break. Decrease the amount of time you spend programming, and increase the amount of time you spend with friends, family, being outside, etc. You need to remove yourself; I recommend balance.

</comment><comment><USER11> It sounds to me like you've dug yourself into too much of a rut of how software _should_ be made that you can't just dive into it anymore, and get bogged down in doing everything 'perfect' that you don't get anything done at all.

I tend to just dive in, make a bit of a mess, and refactor/clean things up before I check things in. I think it helps that I have tackled learning quite a few different languages over the years and have done some working for startups (which has no time to get things right, it's just got to get done before the whole ship sinks).

Just pick a little piece of what you want to work on, get that working, then add another bit, and another bit, until you have a full feature but still runs, then clean it up, check it in, and move on to the next tiny piece. Don't worry about documenting every little thing.

Learning a new language, especially a scripting language that can get things done in a few lines of code and people don't obsess over diagrams and graphs of the system could help. Python filled that niche for me.

Good luck!

</comment><comment><USER12> > it's getting from what needs to happen to how to decompose into > classes/methods/libraries

Perhaps the problem doesn't fit into an object oriented solution. You could try learning a functional language and see if you find it fitting better. I struggled for years with OO and was never happy with my solutions. Learning functional was my road to Damascus experience.

If you have to go OO, there have been plenty of people who have thought long and hard about how to make OO a suitable solution. Some classic books you may want to consider :

\- Design patterns : elements of reusable object-oriented software (Gang of four) - there are people who swear by this and turn it into their hammer for which everything becomes a nail.

\- Patterns of Enterprise Application Architecture (Martin Fowler)

\- Refactoring: Improving the Design of Existing Code (Martin Fowler and Kent Beck)

\- Growing Object-Oriented Software, Guided by Tests (Steve Freeman)

<comment><USER13> I would add

\- Object Oriented Software Construction (2nd. Bertrand Meyer)

I would recommend Eiffel if you want to elevate OO design. The issue with the GOF book that I have is that there is a slant towards composition as opposed to inheritance. When done right inheritance does result in compact code. Multiple inheritance cannot be avoided (Scala proves this by trying to bring in traits). Repeated inheritance actually helps reduce the code size as one could inherit the same method twice to implement a doubly linked list from a single linked list.

Note: In functional paradigm (Haskell) composition over inheritance makes sense, though in object oriented languages choosing an approach that has a compositional bias can impose some constraints that could be avoided otherwise.

<comment><AUTHOR> > Object Oriented Software Construction (2nd. Bertrand Meyer)

That was the first programming book I ever bought! Sad to say it's sat unread on the shelf for 13 years...

</comment></comment></comment><comment><USER14> You're thinking about it wrong. Don't think of it as "prototyping" or "just works". If it just works, you're done, there's no need to rewrite it to make it enterprisey.

What about it needs fixing? If it works for 100 items but not a million then fix that. If it works but is difficult for others to change the code, rearrange things until it's clearer. If it works by using some weird 3rd party dependency that wouldn't be easy to deploy and update, just remove that dependency, etc. If it works but you don't have an easy way to build or deploy it, then work on the build system. If it's buggy, fix the bugs.

Don't make things more abstract just for the sake of abstraction. Don't add message passing or enterprise logging just because they're enterprisey. Ask what problem you are trying to solve by adding these.

</comment><comment><USER15> jaredhalpert says take a break and he's right. eigenrick says shake things up a bit and learn a new language he's also right. Sebastienconcpt says get a fresh pair of eyes, he is also right.

You just need a jolt. If it's feasible take vacation and build something fun in a brand new language that is really different from anything else you've ever used. Set goals like I'll work on this no longer than X hours a day where X is small. Don't set deadlines for completion. The goal here isn't a finished product it's to have fun tinkering with something that will break you out of your block. And pick a language with a welcoming but passionate community that can give your feedback on your code.

I do this all the time to keep myself fresh working on open source projects or playing with new things. It expands my toolbox and gives my brain a break from the constant legacy enterprise spaghetti-ware we so often work on.

And when it comes to your money earning work don't discount the Just Works outcome. When you are glueing together legacy systems sometimes there is no "beautiful and elegant" solution. Sometimes due to time and legacy constraints your only option is duct-tape and bailing wire. Having an outlet to write more elegant stuff in your spare time can be a valuable sanity saver.

Side Note: I wonder if there are any good places online to have virtual design reviews done? Somewhere where the high level goals and constraints are listed and people comment on the best way to achieve them? Language and platform agnostic preferrably although some suggestions will inevitably work better in some languages than others.

<comment><AUTHOR> > And pick a language with a welcoming but passionate community that can give > your feedback on your code.

Any recommendations? The PHP community (where my commercial work is done) is not that. And far too fad driven.

> And when it comes to your money earning work don't discount the Just Works > outcome.

You're not the first person to say that to me. I should start listening!

> Having an outlet to write more elegant stuff in your spare time can be a > valuable sanity saver.

Agree - if I despise what I write every day, it wears me down. I haven't worked on anything fun (or open source) for years, focusing on making money.

Thanks mate!

<comment><USER15> It's hard to say without knowing what's already in your current toolbox. But a partial list might be:

* Erlang - Novel approaches to fault tolerant system design. Fail fast and recover somewhere else. Functional without the Type wizardry so you learn about immutability, pattern matching, and the typical functional language tools like folds, maps and so on.

* Clojure - A lisp that runs on the JVM. Learn about Code as data and how that empowers meta-programming. Also a functional language with interesting takes on how to share data in an immutable by default world. Lazy collections of a sort so you can learn about laziness.

* Haskell - Don't let the Category theory stuff scare you. Very interesting type system that can open your eyes to new ways to abstract things. Speaking of abstraction Haskell takes abstraction to a whole other level. Sometimes you can't see the program for all the abstraction going on. Militantly functional.

* Forth - Stack based programming, very small and compact. Radically different than anything else.

* Rust - Maybe you want to go a little bit closer to the metal for a change? Forces you to think about exactly _how_ you share data in a multithreaded world. Targets the same world as C++ but perhaps with an easier to enter community.

* Python - Cleaner more elegant language in the same family as PHP with a very welcoming community. Batteries included so it's easier to get started than any of the others.

* Go - Concurrency done right. Lots of tooling builtin to the distribution toolchain.

<comment><AUTHOR> Nice list, and overlaps a lot with my "Languages to try one day" Post-it note (though I have Elixir instead of Erlang). And I'd never heard of Forth - amazing what I learn!

My current toolbox is:

Professional level: PHP, databases, frontend development (but haven't picked a JS framework due to choice paralysis)

Experience of: C, Python, Matlab, Fortran77, Prolog (my favourite, most mind- bending experience yet. Magic!)

I tried learning about monads recently. [https://www.youtube.com/watch?v=UvD1VjRvGIk](https://www.youtube.com/watch?v=UvD1VjRvGIk) made sense (I was nodding my way through) but I kinda missed what a monad was - this just seemed common sense that my languages didn't allow :)

Thanks, you've inspired me to play.

</comment></comment></comment></comment><comment><USER16> Don't decompose up-front. Instead, take your prototype and and start adding the polish necessary to turn it into a finished product. When a subsystem starts getting so complicated that can't understand it when you're changing it, look at that subsystem in isolation and figure out how you might refactor it to eliminate code duplication, create simple interfaces, etc. Eventually you end up with clean system boundaries separated by message passing, but each individual step doesn't require that you hold the whole system in your head.

</comment><comment><USER17> How exactly does the "mental block" look like? Does it mean that you see several possible approaches and struggle to decide which one to use? Do you feel the pressure of the "into something maintainable that will run for 5+ years" requirement?

If the answer to 2nd and/or 3rd question is "yes", your description sounds like a specific phase in the process of your professional development.

A lot of people grow with their competences (be it knowledge or skills) to the moment when they start to realize the limitations of their competences. The moment when they see a bigger picture of their work, the broader consequences of a possible error, they feel bigger responsibility etc. It's a moment when doubts start to creep in and self-esteem plummets. The paradox of this phase is that objectively such people are very competent and capable to solve the problems they face. But they become paralyzed by the pressure and self-doubt.

If this reminds you your situation (at least partially) then the solution is called coaching - a method created to help competent people who lost their faith in own competences, overcome the difficulties and grow further.

Other (often proposed, even here) solutions like switching a job, going to some seminar, being more controlled by your boss or taking a vacation do not solve this specific problem, and quite often lead to bigger decrease in self- esteem.

Hope it was helpful and coherent - it's quite complicated subject to present in a short comment.

<comment><AUTHOR> > How exactly does the "mental block" look like? Does it mean that you see > several possible approaches and struggle to decide which one to use?

Sometimes yes (paralysis by choice), but in this case no. In this case defeat and "I can't do it" are my initial response, and I shy away from programming.

> A lot of people grow with their competences (be it knowledge or skills) to > the moment when they start to realize the limitations of their competences. > The moment when they see a bigger picture of their work, the broader > consequences of a possible error, they feel bigger responsibility etc. It's > a moment when doubts start to creep in and self-esteem plummets. The paradox > of this phase is that objectively such people are very competent and capable > to solve the problems they face. But they become paralyzed by the pressure > and self-doubt.

That fits. I know I know nothing. Then I wonder what it means to know. What is meaning? You get the picture - it's a destructive deconstructive spiral brought around by doubt. I inhabit "Imposter Syndrome", still trying to find a way out.

> If this reminds you your situation (at least partially) then the solution is > called coaching - a method created to help competent people who lost their > faith in own competences, overcome the difficulties and grow further.

Do you have any pointers for finding a competent coach please, vs someone who's overconfident in their own abilities?

Thanks for taking the time to comment, you've been really helpful.

<comment><USER17> >defeat and "I can't do it" are my initial response, and I shy away from programming.

Was it always the case? Also: how do you finish your projects then?

>a competent coach please, vs someone who's overconfident in their own abilities?

I'd say that anyone demonstrating a strong confidence either in the results (ie. guaranteeing to help you) or own skills (ie. talking a lot about self) has a giant red flag over his/her head. Good coaches have an interesting mixture of modesty (no bragging), genuine focus on other people (more questions than statements) and assertiveness - healthy interpersonal strength when it comes to the coaching process, tools etc. Ideal coach will:

1\. Be very clear upfront about the distribution of responsibility between him/her and you - it should be ~50-50. That means that being a coaching client is a quite a challenge and it isn't always an easy experience. Anyone painting a sunny, broad staircase up for you is a red flag :)

2\. Recognize you as an individual - without jumping to conclusions too early.

3\. Describe you the idea of coaching and how it is different from advice, counseling, therapy and other forms of help which are sometimes confused with coaching. Anything what smells new-ageish or like proven receipt for success = mega red flag :)

4\. Describe you the process you will go through. Usually it's something like: analysing your needs->setting development goal(s)->performing some action->discussing the action+feedback->setting next goal and this repeats until your main goal is reached (or the agreed upfront number of sessions is finished). It's very important that coaching is like a good project: it has clear, measured goal and is meant to end at some point. If the end is lost in a distant fog - yes, it deserves red flag.

5\. Be very precise and metrics-oriented - there's no place for unclear mumbo- jumbo in coaching. Unless someone likes red flags of course :)

So, these are the essential characteristics. Also it is very important that you should feel comfortably in contact with that person - imagine openly discussing your struggles, doubts as well as receiving feedback form him/her. Regarding formal requirements: respected certificate (ICC/ICF/IIC/IAC) is a proof that someone was trained enough to know the process and toolset. But certificate isn't necessary because the process&tools are actually quite easy to learn - everything depends on mindset/attitude and that's something what could be shaped during the training but as usual - no guaranties.

Feel free to ask if something requires more info.

<comment><AUTHOR> > Was it always the case? Also: how do you finish your projects then?

No. Until I was 12-13 I had a real 'can do' attitude; I executed and others looked on in amazement. And up until 5-7 years ago I loved programming and making the computer do things.

Thanks for your excellent pointers to assessing a good coach - those are going to be really helpful. I only have a question about 3) as I don't know what the difference is myself :)

> 3\. Describe you the idea of coaching and how it is different from advice, > counseling, therapy and other forms of help which are sometimes confused > with coaching.

</comment></comment></comment></comment><comment><USER18> Your #2 is drastic. Your #1, reasonable, and Martin Fowler is your friend [1][2].

[1]: [http://www.martinfowler.com/articles/enterprisePatterns.html](http://www.martinfowler.com/articles/enterprisePatterns.html)

[2]: [http://www.amazon.co.uk/Enterprise-Integration- Patterns/dp/8...](http://www.amazon.co.uk/Enterprise-Integration- Patterns/dp/8131725081?tag=duc08-21)

[edit: beefed up]

</comment><comment><USER19> If the code is tested then refactoring the ideas contained within is the way to go. Do the smallest refactorings possible. Even well-respected programmers who've authored tons of books and given talks do not sit down and 1-shot a program. Elegant programs are the result of refining and designing.

The earlier in the development process you get to the refactoring and isolating minimal testable components, the less of a tangle you have between components to refactor; it's a lot like the wire tangles we're all so familiar with). This not only means less refactoring, but it also means that the existing code is easier to understand.

The tests are code. Treat the tests just like the rest of the code. I prefer test-first but if you want to pull your cart in front of your horse then go for it.

If the code is not tested I'd recommend testing it. There are really only 3 options to go from untested code base to tested code base: \- Try to put tests under existing code (often inefficient) \- Refactor the system incrementally as time goes on and features are added and bugs are fixed (slow process but over time test coverage grows) \- Throw it out and start over (ouch but... greenfield; if you do this you should _NOT_ add _any_ new features to the live/production system or you'll end up in a rat race between the two forever)

Also if you're able to take any time away (preferably measured in days) the fresh perspective might help too. Sometimes that little bit of total separation is enough to come back and read a method name and wonder why the hell it's even in that particular class. This scenario could be an early warning for burnout too, take care of yourself!

<comment><AUTHOR> Testing. I have never done TDD; I put it off in the beginning as an extra cost to clients (or time lost for me), and then when it became trendy I (as ever) disliked the trend :) Ian Cooper sums up my thoughts better than anyone else: [https://vimeo.com/68375232](https://vimeo.com/68375232)

I'm doing a rewrite of a small project and that seems ideal to give it a go. To me functional testing is much more appealing, testing a simulated user's experience through the website, yet TDD seems more popular - as easier?

> This scenario could be an early warning for burnout too, take care of > yourself!

I've been in a burnout cycle for the last few years - a holiday in July was the first time I switched off in 15 years, then a health scare last week and a friend in palliative care have pushed me to reconsider. The lure of money isn't as strong as it once was.

<comment><USER20> I think TDD is a great exercise to do a couple of times, and a great way for a new developer to grow some good habits very quickly. I'm much, much less convinced of its utility for people with experience.

However, you really do need some automated testing. One of the reasons I love automated testing is that it permits me to make (nearly) monotonic forward progress on my tasks. If part of your burnout here is that you are just [expletive] tired of making changes in one bit of the code just for it to create 6 more bugs in the rest of it, automated testing is the core solution to that. I used to get that type of burnout... I don't anymore, except when I'm stuck crawling around somebody else's code base where I can't add testing for some reason.

Also, rather than posting another comment, rather than a new "field" you may just need a new _job_. It isn't all CRUD coding. Mind you, there isn't really much out there that is fascinating cutting-edge research every day, either; even that involves a lot of grunt work. But it isn't _all_ CRUD work out there, either.

<comment><AUTHOR> > However, you really do need some automated testing.

How would you distinguish automated testing from TDD?

> If part of your burnout here is that you are just [expletive] tired of > making changes in one bit of the code just for it to create 6 more bugs in > the rest of it, automated testing is the core solution to that.

I do so much legacy maintenance/development, and yes this would make my life a lot easier. Not for my edits creating bugs (ok, sometimes ;)) but for platform runtimes changing and ensuring nothing breaks (PHP 5.3 => PHP 5.6 for example).

A new job... yes it's easy to get pigeonholed into a field. The work I've loved the last few years has been tasks like "develop a custom plotting algorithm so overlapping points aren't hidden (and labels don't overlap)". This has been the work that's fallen in my lap; I haven't found a source for such interesting projects (the ones that push me into areas I don't know).

Though that exciting plotting algorithm also required an entire CRUD admin interface which nearly killed me (from lack of motivation). I need to outsource those bits...

Alternatively there is the "productized consulting" route, but until I have a product idea to productize I'll stick with what I do well: problem solving :)

<comment><USER20> "How would you distinguish automated testing from TDD?"

I would consider the distinguishing characteristic of TDD is that you write the tests first. There's varying levels of strictness there from little more than that restriction, to varying levels of dogmatism on writing code that _only_ makes the test pass.

I consider this a great way for a new programmer to learn how to really _design_ code. In fact it's one of the only ways I know to practically teach design. However, once you have experience, the really dogmatic TDD involves writing simple tests, then writing code to pass the tests that you, in your experience, _know_ will be driving yourself into a local optima that will not be able to carry the design. But when you lack that experience and knowledge, well, it's a great way to get it while learning a good dose of YAGNI. (Which I do not consider an absolute, but is something everybody needs to exercise.)

In contrast to "TDD" which I consider optional, automated testing has provided so much value to me in so many diverse parts of the stack that I consider it a no-brainer; it is a positive value to any project. The exceptions are things where the code is _so_ not-amenable to testing that it is essentially untestable. Note this _only_ applies to code written by _someone else_ ; if you wrote it, fix it to be testable. In particular, GUIs are a _royal_ pain here. It is my belief this is not a fundamental attribute of GUIs, but a GUI not written to be testable is nigh untestable.

(And if you find it isn't bringing you value, you're probably doing it wrong. There are wrong ways to do it. Test code is real code; apply all the arts of refactoring, DRY, and learning from experience as you do to "real" code.)

<comment><AUTHOR> Thank you, that makes sense and _why_ TDD is so worthwhile for me to start with.

For external services (I rarely write code that doesn't rely on at least one SOAP endpoint) is there any alternative to mocking the service and the response data? And then should your tests also verify that the remote service works according to its contract?

As it would affect data in the live system, I cannot think of a way to safely do it, but 3rd party systems have 'changed' their behaviours before now, and that's a horrible bug to track down.

<comment><USER20> "For external services (I rarely write code that doesn't rely on at least one SOAP endpoint) is there any alternative to mocking the service and the response data?"

In practice, no. Though I prefer some variant to dependency injection to "mocking". I consider the testability a first-class concern and code accordingly. Exactly how this manifests varies suprisingly widely between various languages. You don't mention your language, so I don't have specifics.

"And then should your tests also verify that the remote service works according to its contract?"

Yes, but rather than thinking of that as "automated testing", you're better off thinking of that as "service monitoring" that happens to look like automated testing. Consider something like: [http://n8v.enteuxis.org/2011/06/integrating-nagios-with- test...](http://n8v.enteuxis.org/2011/06/integrating-nagios-with-test-driven- development/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> I recently hit a wall like this as well after designing many apps and enterprise systems.

It was a problem that seemed simple at first, but I just kept banging my head against it. I did exactly what some people described here, switched to a functional language, but that didn't help. I started doubting myself.

I'm though it now, and I like the solution, although it could be better. Here are some points that I've picked up along the way:

\- Remind yourself that you are not only generating value when you actually write code. When you take a walk and think about the problem, draw stuff on paper and so on, this is still work. You are still doing exactly your job.

\- This gets hard when coming up with a design takes longer than usual. It's likely that you have run into a complex problem without knowing it. Endurance & patience is key here.

\- Attack from different angles, don't consider the time wasted if you try something and then end up throwing it away, you will have learned something, even if it just eliminating one possible design option.

After you are through it, you might end up cherishing the experience.

</comment><comment><USER22> [https://www.youtube.com/watch?v=GAFZcYlO5S0](https://www.youtube.com/watch?v=GAFZcYlO5S0)

[https://www.youtube.com/watch?v=iukBMY4apvI](https://www.youtube.com/watch?v=iukBMY4apvI) (javascript module workflow that helped me (frontend dev) to transition to modules)

help?

<comment><AUTHOR> Watching Simon Brown now & will look at his book too, thanks.

To take the current project, I have a CMS, Salesforce and ExactTarget. I'm writing the glue to automate taking new content from the CMS, finding SF users with the right permissions to see it, and emailing it to them via ExactTarget.

All good & working until... do I model it as 3 objects? Which object is responsible for creating the DataTable at ExactTarget (populated with SF data)? How is data going to be passed around cleanly between my representations of all 3 services? Or should I represent the system more abstractly as EmailToSend, EmailContent and use all three services within these classes?

<comment><USER23> Code it each way and post it online and someone will tell you _with absolute certainty_ that you are Doing It Wrong because <some fashionable pattern>. Take this person's recommended implementation and post it online and someone else will tell you, again with _absolute certainty_ , that you are Doing It Wrong because <some other fashionable pattern>.

All the while never mind that in 9/10 cases you could have written it either way and it would be of sufficient quality and performance, run more or less without issues for years, be conducive enough to periodic refactoring, etc.

I have a similar feeling as you about software today, although I'm not sure if for the same reasons. I look around me and everything is just so damn complicated. Writing code that is small and understandable is ruthlessly mocked, while a gigantic, complex marvel of engineering (that does the exact same thing) is looked upon as The Right Way. Functionality that would take a week or two to implement 15 years ago now takes a month, or three.

</comment></comment></comment><comment><USER24> Design Patterns! As you said your problem is "how to decompose into classes/methods/libraries"

Book wise, I learnt them from "Head first design patterns" which is useful and fun or for a quicker overview - [http://www.java2s.com/Tutorials/Java/Java_Design_Patterns/in...](http://www.java2s.com/Tutorials/Java/Java_Design_Patterns/index.htm) .

Also remember if you have other people around you delegate / meet them / bounce ideas together.

<comment><AUTHOR> I bought my first "Head First Design Patterns" 12 years ago, worked through it, and it didn't make sense. I've dipped into PoEAA and Gang of Four since, with the same problem. The way messy life is meant to fit patterns... it didn't gel.

Any thoughts?

And thanks for your great reminder about meeting up to bounce ideas around. I'm going looking for them.

<comment><USER24> Difficult problem, I do know what you mean about fitting messy life into patterns, that said some can still be invaluable at times.

Something like a singleton would be handy to stop multiple creation of an object, for web design mvc just makes life a lot easier by decoupling different parts and in theory for your project something like an observer pattern could be created to notify other systems to a state change. [http://www.java2s.com/Tutorials/Java/Java_Design_Patterns/01...](http://www.java2s.com/Tutorials/Java/Java_Design_Patterns/0170__Java_Observer_Pattern.htm)

In the end there's many ways and approaches, maybe even brushing up some class design stuff in another language might help.

Good luck on your journey, sounds like you'll be fine.

</comment></comment></comment><comment><USER25> Relax. Anyone who writes software will code themselves into a mess sometimes. Learn to love refactoring.

<comment><USER26> +1

Edit: This. One of the things I see a lot of people running into is this mis- conception of "prototype" -> "production". The prototype is your proof of concept, you take this application and you refactor it and optimize it as you move into your production life cycle. You take the bits out and put new bits in that are either un-optimized or don't work for the entire scope of that specific problem.

Working code is better than nice code that doesn't work. Refactor small bits as you progress.

</comment></comment><comment><USER27> About 2004, I reached a stall state. I did some serious wilderness time and it took about six years to settle down into a new zone.

This was the trigger for me: (1) I had a development career where I tried to build every application centred around databases; (2) I now had enough experience under my belt to join the dots on where this ended up, and to see that this was futile. But I wasn't able to see past my everything-is-a-hammer.

There is a technique I took a lot of value from in moving on, and I still use it most days. It is this: think hard, ten times, about a problem that is tickling you. I went through a notation phase, but now I just type out my stream of conscious into a text document.

In the past, I would have spent a year building the first thing that came into my house. Now I can consider a large number of ideas, and have context for judging them to be good or bad ideas. The first thing I invest development energy in is significantly better than it would otherwise have been.

It's cool too in that you don't need to be at your desk to do it. You can be in a restaurant, or sitting on the beach, or on the bus, or on an exercise bike. My favourite spot at the moment is lying on a couch. The good thing about doing it away from your desk is it takes away the pressure to rush through the uncertainty.

"choreographing 3 enterprise systems to work together"

How do you think about message-passing between them? Why do you do it that way? Think ten times about different approaches you could use. You could use the exercise to force you to question your passive assumptions. You may find that you are scared by uncertainty. Your subsconscious could choose to fix on something familiar, than to admit that it does not know. All the more reason to do this away from your desk. Take a walk.

Feel free to ping me via my account email if you want to discuss your situation in more detail.

</comment><comment><USER28> Is it possible that you're suffering from "Analysis Paralysis"? ([https://en.wikipedia.org/wiki/Analysis_paralysis](https://en.wikipedia.org/wiki/Analysis_paralysis))

If you have 15 years of experience, I'm fairly confident that you know how to solve these problems. In fact you probably know 10 different ways to solve these problems. Maybe the overabundance of choice is becoming the bottleneck?

If so, perhaps there's a way you can simply force yourself to commit to a methodology/problem-solving-method before you start tackling the actual problems. Or, you could try breaking the development cycle into smaller, more digestable, iterative chunks (so that you only have to think about the next small step instead of the whole path forward).

<comment><AUTHOR> > If so, perhaps there's a way you can simply force yourself to commit to a > methodology/problem-solving-method before you start tackling the actual > problems.

I really like that idea. So for a given project where there are 5 ways I can say "I'm going to solve it using approach 4. It may turn out to be better or worse than the others but that's not what matters; using this method is what I'm doing" and have that as my goal, not _finding the optimum method amongst the 5 possible ways_.

<comment><USER28> Exactly. It's almost like recreating the pseudo-efficiency that newer developers seem to possess (I only know one way to solve this, so I'm going to do it that way, and do it fast). In your case, the loss of choice is artificial, but it reaches the same result (getting it done).

</comment></comment></comment><comment><USER29> When you explain your problem, I feel like we might share a trait, which I could pithily describe as difficulty separating/ranking/comparing/organizing/categorizing things. So, I find it very taxing to make the kinds of decisions you describe. I usually get there, but it's heavy lifting for me.

I don't think there's a silver bullet for you; you probably aren't incapable, but you may need to suffer through sub-optimal organization to hone this skill. What I will say is that, if you haven't worked on an existing project with highly complex organization (ideally one that has _problems_ ), doing so might help you. While I envision working directly on the project when I say this, there are cases where working with complex dependencies you need to get custom results out of can also be useful.

The point is that you want to be working with complex software (not simple interfaces) that requires a strong understanding of its internals to accomplish what you need. You'll know you're working on something on roughly the right magnitude of complexity when you regularly realize that your understanding of how the project or dependencies work is wrong, and your solution doesn't account for some hitch in how they work. The meta-point is that you're working with sub-optimal decisions other people made, and you either just have to deal with them and simmer to yourself about how _you_ would reorganize this mess if it was within scope, or you have to start refactoring their code (or building your own interface with it) that solves the problems with their design. The meta-meta point is that we're better at seeing problems in work other people have done than our own, but with effort we can train our eye on other people's work and (eventually) learn to focus it on our own.

At it's core, I think this is really about the cognitive overhead associated with working on and understanding a given implementation, so working on things that are cognitively overwhelming provides you an opportunity to learn about how to manage cognitive overhead. The result is hopefully that you learn to wrangle that complexity into an understanding that helps you do what you need without doing surgery, you build an interface that reduces the cognitive overhead enough that you can do what you need, or you refactor to accomplish the same.

</comment><comment><USER30> For me, a lot of this stuff only comes through trial and error. It's not ideal, but I think over time, both the trials and errors improve in quality.

Basically as I work in the code, I see little things that could be easier or make the code clearer. Then sometimes I get ideas for big changes. Sometimes the changes make things worse, but that's why we have revision control right?

I think the same goes for drawing. Just get something on paper and look for small changes. As you make changes, eventually you might see a larger change.

</comment><comment><USER31> Whatever it is, it is only so different from your past work. It may help if you sit down and try to put together an argument either that you can or you cannot do the work. I would be skeptical and rigorous about it and try to force it into defining exactly what it is that you cannot do. Chances are it is a matter of framing up the work, and in trying to prove the work is impossible, you will probably frame it up and make it be possible.

</comment><comment><USER32> It seems to me it may help, if you have not done so, to refresh yourself with some basic abstract math .. starting with set theory, topology, abstract algebra such as group theory and group representation .. it would illustrate how to walk up and down on the abstraction ladder to get to the essence of the problems at hand .. once you have got the essence .. you would be liberated and can spin it any ways you like ..

</comment><comment><USER33> If at all possible, take a vacation where you do anything _but_ code. Pull the plug, if only for a week.

<comment><AUTHOR> I hate to say, I'm just back from a week's vacation. I struggled to switch off & went down with shingles (brought on I am convinced by the work stress)

<comment><USER34> Give yourself some time to get back to healthy... any kind of health issue can cloud your judgement. I always try to refrain from making big decisions when I'm not feeling good. Shingles sucks, and the pain can linger... hope you're doing better now!

<comment><AUTHOR> Thanks! The antivirals are doing magnificent work. The pain... is slowly improving. Not bad for 1.5 weeks from first appearing.

</comment></comment></comment></comment><comment><USER35> Do you have any training in UML? I feel that learning basic things like domain diagrams, sequence diagrams, and state diagrams help decompose complex systems into maintainable chunks.

</comment><comment><USER36> You could stay in your field, a field that you obliviously love, but try at another company where you would have better ressources / coworkers at your disposition.

Take days off too.

</comment><comment><USER37> Everyone's style is going to be differ on the high-level stuff - and you are surely well beyond the point where any random blog post blabbing about software architecture can guide you.

Keep walking back to the user and business requirements when you're in doubt. In senior technical positions, you aren't focused on immediate issues in the code, so much as on developing the right processes to attack those problems. Software isn't expected to last very long, and when it does it's both miraculous and ugly, as the tools and techniques become more and more arcane over time. If the solution you develop can satisfy all parties for an extended period, it is as correct as you can hope for - and part of that involves choosing a technical process that can be kept running in an environment of some ineptitude.

When you know the requirements, model the data first. Data comes first because data lasts longer than code. Flexible data lets you do more with less code. And if the data is very well defined you can usually use fewer language features, too - which is a bonus to maintenance later. Think of features in data terms first and lifecycles later.

The best-practices cruft you've learned over time - that's going to have to be sacrificed when you identify ways that your designs can be simpler. You may identify a pattern that is useful but not "with the grain" of the languages you're using. That doesn't mean it's wrong, just that you're breaking past some known boundaries of programming.

As you know, most projects get dirty in order to ship. Not doing that means doing basic research to find the ideal technique, whereas there's always room to tolerate a few more hacks, global flags, mystery-meat callbacks, etc. Your best defense is for the data to be so good that all the code can remain disposable and the system will still turn out more-or-less the same way if rewritten from scratch, with a different-but-equally-awful set of hacks and kludges.

Under the pressure of strong data, code that sticks around after several cycles of disposal becomes the library code by default - and internal APIs will become strong enough to prevent a "lava layer" from taking root, because they'll consistently solve the immediate problem faster than any wrapper layer. The maintainers will feel like geniuses because they'll keep finding clever ways to use the existing data better, instead of mashing out another travesty of reflection and classes-on-top-of-classes.

If data isn't sufficient, you may also have to define a protocol. Protocols, if they work correctly, compact the state management into a small part of the app, and leave you with more data.

<comment><AUTHOR> > When you know the requirements, model the data first. Data comes first > because data lasts longer than code. Flexible data lets you do more with > less code. And if the data is very well defined you can usually use fewer > language features, too - which is a bonus to maintenance later. Think of > features in data terms first and lifecycles later.

Boy am I SO GLAD to see someone say that! I think of my approach as "Data- Driven Development", rooted in my days of scientific programming. The data is what matters. On my largest project to date (8 months, entire business system) I spent 25% of the time just on the data store schema. Needless to say it worked & evolved without issue over 5 years.

Yet (at least in the PHP community) the fad is currently Domain-Driven Development, BDD, and architectures ("another travesty of reflection and classes-on-top-of-classes").

> The maintainers will feel like geniuses because they'll keep finding clever > ways to use the existing data better

Oh yes, that's how my oldest systems are. Spaghetti code in parts, but the data keeps on giving.

Thank you for taking the time to write this, you've ignited a small flame of enthusiasm in me and reminded me why I enjoyed doing what I do!

</comment></comment><comment><USER38> 5+ years? That's crazy for web applications. I cant imagine any code lasting more than two years nowadays

</comment><comment><USER39> Quick question -- do you use unit tests?

<comment><AUTHOR> No. I missed the boat, then I felt functional testing was more important. Ian Cooper sums up my thoughts better than anyone else: [https://vimeo.com/68375232](https://vimeo.com/68375232)

</comment></comment><comment><USER40> It's hard to tell without looking at your code, but I suspect that you are stumbling in to a wall that many do. What's in your favour is that you recognise it, so you will probably be able to do something about it.

Systems grow over time. At the beginning, they are simple, which means that they are forgiving. If you make a mistake, it is easy to see and correct. As the software grows, it gets progressively more complex. Problems hide for a long time and when they present themselves it is often very difficult to see the actual problem.

What I'd like to do is challenge you to look at it a bit differently. Think about the number of lines of code in the OS, system libraries, language, libraries, frameworks, etc that actually go into your code. Even if you only write 2 lines of code, there are probably hundreds of thousands of lines that your 2 lines are sitting on top of. Why are your 2 lines easy to understand?

Obviously because there is a great separation between the complexity of the underlying systems and your code. What you need to be able to do is to provide that same separation in your own code.

As you mentioned that you don't work with others, I will recommend some other approaches. However, if they don't work, I recommend that you change to an office job where you can get the mentorship you require before you leave the field altogether. 15 years is a lot of learning to give up.

#1: Read good code. One of the biggest problems that programmers have is that they rely on their own code for examples of "good code". You are at a huge advantage because you recognise that you need to improve your code. What should you be reading? Read library code from whatever libraries you are using. As you are doing "web development", I would advise you to shy away from reading the source code of frameworks like Rails, but rather read the underlying class libraries for the languages you use. If you are not using languages that are open source, then it will make your life much more difficult, but try your best to find open source and free software on the internet to study.

#2. TDD. Every time. All the time. Not BDD (although BDD is an excellent practice in its own right). You want to do TDD. This will force you to think about your interfaces and to decompose. There are many books about TDD. Some of them are good and some of them are bad. Read Test Driven Development: By Example by Kent Beck. It is probably not the best book on TDD, but it will give you the basics without confusing you.

If you are working with legacy systems and don't know how to TDD with those legacy systems, read: Working Effectively With Legacy Code by Michael Feathers. It is a very, very difficult book. Learn it all.

You may hate TDD. Many people do, but using it will make you a better programmer. Personally, I don't think it's bad if you abandon it eventually, but master it before you do. This will simplify the process for you and break it down so that you can consider things in more manageable pieces. It will move you away from "Just Works" because it is god awfully slow (or at least it feels that way). Just pay attention to the effect it has on your code.

From where you seem to be now, to where you want to be, I estimate you've got 2-5 years of effort. Don't get discouraged if it doesn't come right away. This is a discipline where you can get orders of magnitude better over time. Try to be as patient as possible.

I hope this helps.

<comment><USER41> I agree with a TDD, but it really depends on the framework/cms you're working, some of them are incredibly hard to write tests agaist. One of the examples would be writing unit tests for the WordPress plugin, if you're sticking to the WordPress way of coding unit testing is practically impossible because there is lot's of database access and events which do mess up.

You can write plugin folowing OO principles and abstract things out to be able to mock them as nessesery. It really depends on the coding standarts you're folowing.

As for unit testing. In my personal experience it enforces you to write cleaner code, because when I started I had to do heavy refactoring to be able to test my prototype, but as I wrote more testable code I started separate unrelated parts which reduced amount of spagetti code.

Another way to achieve cleaner code in my opinion would be design patters which lets you separate code logically(for example MVC), and make some things cleaner(I'm big fan of laravel's Facades for example).

</comment></comment><comment><USER42> I'm confused why you list only two options.</comment>


GitHub now uses native fonts (San Francisco in macOS and Segoe UI in Windows) - <AUTHOR> https://github.com/? <comment><USER3> Fix it with stylish, if you don't like it: [https://twitter.com/barakmich/status/752568316485627908](https://twitter.com/barakmich/status/752568316485627908)

</comment><comment><USER4> To be more precise, on macOS it's using system fonts (`-apple-system` - <USER2> necessarily San Francisco if set otherwise or on older versions of the OS).

</comment><comment><USER5> They could be A/B testing this. I'm still served Helvetica.

</comment><comment><USER6> I like it in the readme because it looks cleaner and more readable but for some reason I don't like it anywhere else (file names, etc.). I'm on a Mac.

</comment><comment><USER7> Much nicer--for a while there it seemed like they were headed for 2005 with the typeface, gradients, and other visual elements.

</comment><comment><USER8> Which font depends on whether you're logged in (which is weird).

Why not use the default browser font?

In any case, an unwelcomed change for me.

</comment><comment><USER9> My work machine (Ubuntu 14.04.4) now shows Ubuntu, which is a little less jarring when looking at different places on screen (I use Ubuntu Mono in the terminal), and my home laptop (Fedora 23) now uses Arimo (since I have ChromeOS fonts configured). Nice touch.

</comment><comment><USER10> Tahoma still looks more natural to me inside applications, while Segoe UI looks better to me in the OS itself.

</comment><comment><USER11> No, Sir, I do not like it.</comment>


Ask HN: Anyone ever tried a hackathon while water fasting? - <AUTHOR> I want to specifically know if it helped with speed of execution and creativity. <comment><USER2> Can you ask your real question? Obviously you're not looking for just "yes" or "no". I'm assuming that you're considering doing a hackathon while fasting and have some questions or concerns. What are those questions and concerns?

<comment><AUTHOR> Updated the question thank you.</comment></comment>


Google on hiring spree - <AUTHOR> http://www.theage.com.au/news/biztech/google-on-hiring-spree/2008/01/24/1201025047908.html

<comment><USER2> At least mention in the title that they are only talking about their Australian division which is less than 200 people or about 1%-2% of their employees.

I read the title and assumed they changed their minds on their new slower hiring policy they announced when they realized it is cutting into their margins.</comment>