sghill

Up to what scale?

This works well for a couple dozen repos per team in my experience. It’s also my preferred way to work.

It doesn’t scale so well to hundreds of repos per team without significant tooling. At some point anything cross-cutting (build tool updates, library updates, etc) becomes hard to track. Repos are left behind as folks change teams and teams are reorg’d.

I’ve never worked in a monorepo, but I can see the appeal for large, atomic changes especially.

Definitely - we recently moved issue tracking to another system after 15+ years and found there were too many links to abandon, so we run a service that just redirects old URLs.

Breaking down work so it can be delivered incrementally is an underrated skill.

Simplifies communication about progress, builds confidence in ability to deliver, and makes it easier to avoid getting lost in rabbit holes. Especially in situations where there are lots of unknowns - unknown programming language, multiple tools to choose from, etc.

The old URLs aren’t kept around to redirect to the new location?

I’d like to see better centralized support generally from CI systems. Six months of steady migration and a custom DSL seems alarmingly common.

CI Wishlist:

* testable outside of CI

* required steps based on repo characteristics (ex: security scans)

* central step and workflow definitions

* controlled rollouts/rollbacks to simplify migrations

Guided runs in Nike Run Club are great for this. There are several coaches with different styles.

My favorite have been the Headspace mindful runs[1].

[1]: https://www.headspace.com/meditation/running-meditation

This 2006 Stanford interview[1] with Kelleher sounds like taking ideas seriously was an important part of the culture. Tragic it was lost, as it always stuck out in my mind as an example of great leadership.

> Southwest continues to encourage and applaud out-of-the-box thinking from everyone at the company, from flight attendants to top-level executives. He recalled one mechanic, for example, who submitted a sketch showing how to fit an extra seat onto the aircraft, in order to compensate for some over-wing exit seats lost due to a new federal air safety regulation.

> In general, Kelleher said, if a Southwest employee submits an idea like that, he or she can expect to get an answer back within a week, and a lengthy explanation to boot. The point, he said, is “never spoil an idea, because when you spoil an idea, you ensure that you’ll never get another one from that person.”

[1]: https://www.gsb.stanford.edu/insights/herb-kelleher-manage-g...

> Does this new language save you that much over using a more generic and widly known language in the org?

This is a great question to ask. It’s worth extending beyond language to frameworks and libraries as well.

It’s important to optimize for the development experience across all the apps in a team. Especially once the excitement of using a new language is gone and there are bugs to fix.

I‘ve rewritten a few projects in a common language for the org. Each time the biggest benefit was how straightforward it became to work on. Problems you’ve found somewhere else become easy to spot (and search for). Writing another test is the same as the last project you had open. Anyone in the org can contribute with a minimal learning curve. This can be the difference in getting bugs fixed in a day or a month.

I've been a subscriber to NHL Gamecenter for two years. If you're very far from your home team, it can be a good deal.

In California, I can catch most of Detroit's games. In a major hockey market like Toronto, however, Detroit's games are often on TSN2 (think ESPN2), which means they are blacked out. Cable was the only way to see these, even though I would have guessed they were out of market.

It does sound like they were debating this for quite a while. Eric Lippert used to work on the C# compiler and published a blog post[1] immediately after the announcement:

    Since I always knew that open sourcing was a possibility I tried to write my portions of it as cleanly and clearly as possible; hopefully I succeeded.

[1]: http://ericlippert.com/2014/04/03/c-and-vb-are-open-sourced/

I found the IntelliJ docs[1] handy for discovering predetermined variables like $END$ and $SELECTION$.

[1]: http://www.jetbrains.com/idea/webhelp/live-templates.html

    When 90% of your "students" fail to complete the courses, you have an epic failure on your hands. MOOCs are not working.

I completed every course I signed up for when I was going to university. Completion percentage was important because I was, and still am, paying to be there. As a result, I enrolled in very little that I was simply curious about. Virtually every class I took was a step toward a degree.

Since graduating, I've enrolled in a handful of MOOCs. I've finished less than half of these courses, but they have satisfied my curiosity and have given me something new and different to learn. I most certainly would not have paid for the experience, but I feel I'm better off because of it. I'd say this is working and far from an epic failure.

I haven't used a serious app in production on OpenShift, but I have been playing around with a Java project recently. Assuming I get it to production, I'm going to stick with OpenShift. I think the blogs, forums, and docs are great.

I started out with gradle and embedded jetty, and found no out-of-the-box support. They did do a nice blog post on how to use gradle for builds[1]. Unfortunately, the blog uses gradle version 1.6 and that's the last gradle version that doesn't throw an exception while building[2].

Wanting things to be easier, I switched over to maven[1] and tomcat:

    OpenShift has supported Apache Maven as default build system for Java based projects since the first release.

Since going with this setup, things just work.

I also really like that the environment configuration is stored in the codebase under the .openshift folder. This makes it very easy to, for example, develop locally against http but make all your traffic go through https on OpenShift. And the free piggyback ssl means https just works too.

[1]: https://www.openshift.com/blogs/run-gradle-builds-on-openshi... [2]: http://issues.gradle.org/browse/GRADLE-2871

Flask and Rails have different focuses. I've used both and like them both quite a bit, but I've found there is often a clear winner depending on the task at hand.

Flask is a microframework that often fits within one file and is probably more comparable to Sinatra than Rails. I've only ever used it for setting up really small webservices and stubbing webservices. It could certainly scale up to larger apps, but it doesn't give you a lot of direction in how best to do so.

Rails is a full-stack framework. Out of the box it gives you everything from the view to the database and strong conventions for where to place classes as your app grows. In general, it's more often compared to Django.

Fair enough, I'd be reacting similarly I'm sure. I get that two years is too short, but how long do you expect a device like this to be supported? I think I recall three major updates for my original iPhone, but by the last update it was almost unusably slow.

> Buying whatever Nexus is out there when I needed a new phone has always been a no-brainer. Not so anymore.

Interesting, I would not have expected so much importance to be placed on unspecified rolling updates.

My current phone is the only Nexus device I've ever had, but it was easily my best unlocked option at $250-300 US. I think that holds whether it's running 4.2 or the latest.

It's even possible to ride a driverless train in the US, and has been at least since the Detroit People Mover[1] opened in 1987.

[1]: http://en.wikipedia.org/wiki/Detroit_People_Mover

I've always found it a lot more effective to sit down with someone and find the answer together, no matter how simple the question. If our technique works well, I've found they'll generally try it again the next time they have a question.

Unlike sending this link, figuring out things together doesn't leave teammates avoiding and dreading interactions with each other.

> Hyperloop is all about passengers (something the rail industry has never cared out)

This is disingenuous. In the 150+ years of North American rail, many of America's most intricate architectural structures[1] are train stations, and they certainly weren't making that investment for freight. The dining car service was also typically a loss leader, designed with the sole purpose of attracting customers. Freight never complains, though, and ends up being much better to transport.

[1]: http://www.nps.gov/stea/planyourvisit/lackawanna-station-100...

Yes. As an industry, we're not very good at recognizing the great things people do. We tend to focus solely on mistakes. It's not easy to admit failure, and if we want it to continue we should recognize the effort it takes.

> There even exist situations (in the case of some positions) where you will be talking to a client of the company you're working for, effectively interviewing with the client, representing the company.

What positions would require you to prove the technical capability of your company at this level?

I've been working for a consultancy for a few years now. I can't recall a time when a client asked me to describe a closure or what I thought of !important. If I'm on a development team, the conversation with clients is generally about the time and effort required to implement something, or the options we have for delivering the functionality. If I'm pulled into a sales meeting, it's usually high-level architectural discussions.

> Screw going to amazon et al to buy anything that changes as constantly as a car. or a cellphone.

You've made it clear you're a person who requires extensive test-driving. Amazon's cell phone business doesn't seem to be hurting. I've ordered my last two cell phones online sight-unseen. Same for recent laptops and a Nook. I'll take the uncertainty of holding a modern device over the sales staff.

> I bet my right arm that you wouldn't ever buy a car from amazon if you couldn't test drive it at the local shoddy dealer.

The average car age in the US is now 11.4 years old[1]. My car will likely be 15 before I get another one. In VW's terms, that's at least three generations of progress. I'm buying a car for a decade, and none of the problems that come up in a decade will be revealed by a test drive.

Regardless, I merely agreed it wasn't currently an option and the parent may have a better experience with the internet sales department of his or her local dealerships.

[1]: http://www.edmunds.com/car-news/average-age-of-cars-in-us-ju...