People share and reuse snippets of unattributed snippets of MIT-licensed and GPL-licensed code on the internet all the time, StackOverflow, etc.
StackOverflow is profiting from that activity indirectly by facilitating it. They profit passively through ad revenue, and actively through the Teams subscription offering.
But nobody seem too upset about that.
How is an AI which facilitates the same code sharing fundamentally any different? Because it’s scraping it itself, rather than humans contributing it?
Best of luck with Zed, Nathan! I've always been impressed with your brilliance, vision, hope, and positivity. Hope we can catch up again soon, until then keep changing the world for the better!
TL;DR: It is a JAMStack-style static site, which we publish with the Middleman static site editor.
However, there's a lot more to it than that, and it's always actively evolving.
There's not currently a page which summarizes the architecture, but there are multiple pages and docs which are focused on processes around editing and maintaining the site. Here is a link which is a good starting point to see what's under the covers and how we use it: https://about.gitlab.com/handbook/git-page-update/#11-start-...
Having done TDD mostly full-time for well over a decade, I have to agree, and it hits home with some past experiences.
You can end up with fully tested, TDD'd code, that is not well-designed - i.e. unnecessarily coupled, and not cohesive. Cohesion and coupling are the basis of most everything in good software design - e.g. all the letters in SOLID boil down to those two things.
The premise of TDD is that it's supposed to make that too painful to do to a damaging extent. But, if you keep ignoring the pain, perhaps in the name of a "spike" solution, or because you just don't have the experience or background to know what good design is, you will end up with a tested mess of spaghetti.
And that's even harder to untangle and refactor than untested code, because you have to figure out which tests are useful, useless, or missing. That just slows you down as you work towards a better design.
In these situations, scrapping the whole module, including tests, and starting over, is sometimes faster in the long run that trying to refactor incrementally with the safety net of existing tests (another of the main values of TDD).
Good article. I think there's a shortage, and I also think technology overload and the ever-increasing rate of innovation and change prevents many junior programmers from really learning agile fundamentals well. There's just too much other stuff to learn that changes too fast, as well as general societal information overload, to get into the deep philosophical fundamentals of agile and OO. I spent hours reading the TDD Usenet list when I started. Who has time to do that now?
> I'm just in the process of cutting a clients hosting costs by about 80% by ditching AWS for a setup on managed servers...
And what are the additional long-term development/sysadmin costs of having to manage those servers and infrastructure?
And how did the client factor in the risk of being tied to you and your knowledge of this particular managed server setup?
And how did the client factor in the risk of being tied to a particular vendor's managed servers?
It may very well have still been the right decision for the client to move from cloud to managed servers.
However, my point is that if you solely base the cloud vs. managed decision on hosting costs, you are ignoring other real long-term costs and risks that are not as readily apparent, but can still have a significant impact in terms of upgrades, maintainability, downtime, availability, changes in personnel, etc.
Things are not always as they seem. The goals of this (Pivotal Labs') office layout and the company values are actually contrary to what you might assume.
In fact, they have evolved to help avoid and weed out the type of employees which the original article warned of - i.e. "The Flake", "The Heretic", "The Jerk"...
I've worked at Pivotal a long time [1], and here's the reality behind what you see in that picture (http://wrd.cm/1rseFPe):
--------
Close Quarters
Most of the people in that photo are programmers who are pair programming, or are designers, produce managers, or testers working closely with programmers. The close quarters are intentional, and intended to facilitate quick and easy communication between all of those team members, and minimize all feedback loops.
This means that the any one of those people can immediately ask another about any question or problem they might be having. A tester can ask a programmer about an edge case; the programmers can ask a product manager to clarify some requirements; a programmer could ask a designer to clarify exactly how a UI is intended to behave; etc...
The other thing you don't see is the huge open space in the rest of the office. It's an entire floor, with large areas for sitting, eating (catered) breakfast, playing ping pong or guitar, or having a morning standup meeting attended by several dozens of people.
These folks can get up at any time, and take a stroll, get one of the many free snacks or beverage, or step into a Tardus-style phone booth or privacy room for a private phone call.
--------
Privacy, "Anything you do on your screen 2 other people are going to inevitably see it"
Exactly. At least for the pair programmers in that picture, what they do on your screen is not private. Because it shouldn't need to be.
Because of pair programming and frequent pair rotation, there is collective code ownership. Two people always work on the same workstation. When a pair is working, they are working - not reading Twitter, not playing with their iTunes playlist, not reading email. They are programming, and always open to questions and interruptions from anyone else on the team.
There are no assigned workstations. Pairs switch up all the time, and work on new stories. The iMacs there all have a secondary monitor, keyboard, and mouse attached for pairing. At any time, the machine can be automatically re-imaged as needed.
Any personal email or other personal activities can be done on separate dedicated email machines at the end of the aisle, or on a personal laptop or phone, but NOT when you are pairing.
Of course, due to the nature of their jobs, designers and product managers, and sometimes testers, do not pair, and thus have dedicated workstations or laptops. But there's still no need for what they have on their screen to be "private", other than email or documents, and nobody is going to bend over and start reading someone else's email over their shoulder. It's a non-issue.
--------
Company Laptops
Most of the people with laptops are either designers, product managers, or testers. Again, because of the nature of their work, they tend to need dedicated machines, unlike programmers who are always pairing. They also tend to need to be more mobile. E.g., product managers taking their laptops to an iteration planning meeting to discuss a backlog. Also, company laptops are assigned for production support, but usually only to be used in during unexpected production incidents or after-hours deploys (which annoyingly don't always observe regular working hours).
--------
Expectation of Working from Home or while Traveling
There is no expectation to work from home at Pivotal Labs. In fact, a 40-hour work week is strongly encouraged and enforced for sustainability (http://pivotallabs.com/crunch-time/). Standup starts at 9:05 (after catered breakfast), and quitting time is 6 PM, with a regular lunch and 15-minute game of ping-pong. No expectation is ever made of working from home, or putting in overtime. Plus, everybody keeping the same hours supports the other values mentioned above - frequent pair rotation, close communication and tight feedback loops. And yes, laptops can be used while traveling, for employees which need them (e.g. product managers or production support programmers/ops).
-------------
So, again, all of these things work together to avoid having employees like TFA mentioned - "The Flake", "The Heretic", "The Jerk". Those sorts of people just don't work out. In fact, because the Pivotal Labs hiring process involves pair programming, including interviewees live pairing with a Pivot on a real project, the most egregious of these personality types never even make past the initial interview stage.
Of course, not everything always works out exactly like I've described. But they do most of the time. The important thing is that they are embedded in the company values and culture, and fully supported from the executive levels and founders - not just paid lip-service.
On a personal note, I have worked at several different types of companies, including ones where I had a dedicated office (with a door) and personal workstation, ones where I had a dedicated cubicle, and also working from home as a full-time remote employee. I will say that Pivotal's arrangement is, in my opinion, by far the best. The energy and enthusiasm that flows through the air is powerful, with so many bright and talented people working hard in the same space, sharing, collaborating, and helping each other out. And playing ping pong.
[1] I've worked at Pivotal Labs (the consultancy) since '96, prior to their acquisition by EMC and subsequent incorporation into the newly-formed Pivotal company.
It is putting a new spin on some traditional Open Source Lessons (https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar#L...).
People share and reuse snippets of unattributed snippets of MIT-licensed and GPL-licensed code on the internet all the time, StackOverflow, etc.
StackOverflow is profiting from that activity indirectly by facilitating it. They profit passively through ad revenue, and actively through the Teams subscription offering.
But nobody seem too upset about that.
How is an AI which facilitates the same code sharing fundamentally any different? Because it’s scraping it itself, rather than humans contributing it?
Seems like a tenuous argument at best.