This is a case for automation or documentation, not specifically docker. Could use anything including a shell script to get this env setup properly. Picking docker means they also have to understand how to manage developing within a docker lifecycle.
Even a wiki page would be sufficient as in developer envs, some understanding of what is being done and why is generally useful.
I don't get the wanting to be anti-social bit, but I do get the part about projects that are sometimes too much about the social bit. Or rather, the stress that can create.
I felt some of this at times, namely the idea of a project became that it must absorb all contributions, and trying to not offend people while trying to mediate that.
This is exactly what a project shouldn't do, and in many cases, it's a giant challenge.
OTOH, much of what spawned good OSS was people working together across company boundaries, and that means letting up a bit to let other people get their ideas in, even if those ideas aren't the ideas you neccessarily feel are the most important.
It's a hard balance.
I do like socializing with people I meet through OSS projects, but it can be hard to close the door and say "this code isn't good enough" and "I'm not interested in this" without being percieved as anti-social, or greatly overcommunicating to avoid percieved slights.
I do agree with one thing I did read about 0mq though, which was it wants to merge things first, and break things. I prefer more to see software that is designed and strictly looked after. The social element is definitely not first, but it sound be fun.
The problem is, with a lot of people in the game and not monetarily invested (this is free, etc), people can get their feelings hitched to the project more than they ordinarily should, if it was a business transaction -- they feel their price for spreading things or contributing should be that the big social element takes over and everybody gets their code in... which is anti-quality in the long run.
Again, balance -- and really only you get to feel this when things start getting really busy.
I do believe software can be finished though. If you're just continuing it to keep the community around, I think that's when you don't have a purpose. But that doesn't really happen unless you're doing it for fun (like a game) - and if so, great!
But yeah, the first goal of OSS isn't just to collaborate for the sake thereof. It should be for the purpose, and you can still enjoy the heck out of the collaboration part.
I think that UNIX-y "do one thing" projects kind of solve the problem. It's easy to reject a contribution as being out of scope: "This little program prints out contents of a file. Your patch that sends it via email is nice, but you should rather make it a separate project built on top of the existing one."
Ultimately the "devops" term is widely applied to a bunch of things, usually meaning one or more of:
* automating things as much as possible - infrastructure as code, continuous deployment, chatops, etc.
* building tools for your organization to use to run your own infrastructure
* fixing cultural and process problems between development and operations and cutting down on change requests, fixing communication, etc.
* Often, about getting developers to build environments where the code they deploy uses the same automation in dev/test as in prod, and more closely resembles prod
* Getting developers to care about production issues
* Getting operations to understand more about development details rather than have a black box they are less likely to understand.
Sometimes the title "Site Reliability Engineer" can mean that, sometimes. Sometimes DevOps means that. Lately "DevOps engineer" means some mix of infrastructure automation (basically systems administration) and writing a few tools or scripts (often these tools require some degree of coding). It can get more custom code heavy depending on the organization, but there's no real standard.
But ultimately, "DevOps" is a (usually confusing) catch-all. Most "DevOps" conference are really a mix of agile, process, and systems administration topics, and many DevOPs meetups are usually about elevating one's game at systems administration and sometimes about Continous Deployment -- though even this can vary.
Personally I like the tech parts and don't care as much for the cultural parts, having found a lot of it, once heard 4 or 5 times, becomes a bit "preaching to the choir" - i.e. folks know it already. Which is why I think once you learn the agile/process/communication bits, the meetups get to be more about tools - these things change and can be new, but there's some percieved duty to keep educating the new folks on the cultural stuff (especially as folks may feel some industries that are less startup-like are slower movers, or for folks in large corps that are slower to adopt things).
It's a catch-all that's used far too often to mean too many things. I once came across a post (from Red Hat maybe?) insisting that "doing DevOps" meant that you "get management and the techies together and talk about the elephant in the room". There was no explanation of what this elephant might be, or how having a meeting was "doing DevOps".
"the other founders are asking me to return some/most/all of the equity that was vested up front."
Don't do this. Most likely this will be used to redistribute this share to themselves or the option pool. They WANT this potential share for themselves if the company is successful, and it's not in your interest to give it up.
You've started things, most likely, and if things were standard-ish, you might have been vesting your stock at 1/48 (or maybe 1/36 or something?) of the total each month (founder shares may also not sometimes not require a year's service to vest). You legally earned what you got during the 1/48 and have no obligation to return anything. The pre-vested up front stuff might have also been sizeable, and most likely will be a foundation for future work that this business produces.
The downside is your last comment about "may start a new company", which seems like they might not be above board. In this case you may need a lawyer, but it might not hurt to contact the board if you have investors on it. If there's no investment, you might have a harder position and you may (I am not a lawyer) need to watch them to see if any of those entities exit. In other words, you might have to sue to get what you are owed for the stock games. Most likely this is an empty threat, and you should probably indicate you are aware of your legal options and reserve the right to exercise them if this happens.
I don't have a great understanding of what happened there, but think about Facebook and what it has done with screwing initial employees from time to time, and they seem to have won at least in part.
Given, if the startup is already crippled due to not being able to work together, the chance of success at the end is reduced. Don't give up your shares - but don't count on them being a thing either.
They should be happy that you still have your shares because you have an interest in seeing them still be successful and are not ALSO going to form a company in the same space. Perhaps. Depends what your exit agreements were, if any. And you should be careful what you sign there as well.
But yeah, sounds like they are asking for things that are not in your interest.
I'd say the opposite - the industry is in general being a lot more comfortable with investing in AWS to the point of lockin being acceptable now. More people are treating cloud providers less like a big pool of IP addresses.
Not saying it's a good or bad thing, but attend AWS reInvent or something and it's pretty easy to percieve huge uptake.
If you adopt extra management stacks running on or against your cloud you lose a lot of the benefits.
That's an interesting perspective and observation. I've always found lock-in to be a bit scary, and I've heard this echoed by a number of colleagues & companies. No one can deny the usefulness of tools provided by hosting providers, namely AWS; however, to me, architecting a system in such a way where you are literally unable to jump ship when the need arises (compliance, cost, etc) is unacceptable. With hybrid / multi cloud more of a reality with the existence of tools like Docker (and others), there needs to exist sets of tools capable of handling such variability. I digress, this really belongs in an entirely different thread.
We tried running on three cloud service providers while connecting back to our own data center (corporate stuff) at the same time, for a couple years, because of the whole "cloud agnostic". The code requires us to be compatible with OpenStack and AWS. Trust me, no matter what people say about the compatibility of some of the components between OpenStack and AWS, you cannot do the AWS-way 100% in OpenStack. In the end I got a pile of shit code with a lot of workaround and condition.
Sure Heat is like a comparable version of CloudFormation, but you can't do what you did in AWS and translate to Heat. OpenStack doesn't have all the services that AWS has. Not every product (and not every API in a product of AWS) works 100% with CloudFormation. If you are running an old release of OpenStack, you are more fucked in that case.
We are now moving our cloud infrastructure to AWS entirely so no more "it works in this environment", or "they sort of work and sort of different because of X and Y tool not comparable."
The right attitude should be "do one thing well, and improve." Architect "right" and than unlock yourself whenever possible. The same goes to people migrating to Docker or any container technology. Dockerfile is a lock-in. You still have to move back to regular shell script later if you drop Docker.
I would tend to agree here to some extent. I think you have to be careful what you lock into. We use RDS and Elasticache but if push came to shove we could easily spin up our own db instances elsewhere or use some other managed service. That being said, locking into something as integral about how you handle your secrets is a big decision. One that when you make, you must be sure you are going to be in AWS for long haul. The reason is how you handle your secrets will touch how everything in your infrastructure is deployed. Migrating to a new system is not easy. (Trust me I am trying to migrate to Vault) For this, I would prefer something less rigid like Vault but I think this tool seems pretty cool.
Does GCE still require that you name (vs simply tag) instances via their APIs in order to create new guests?
That and the slightly weird authentication/setup process (rough memory of that, really) were the obvious downsides for me.
Obvious upsides to GCE would be fractional hourly billing and allegedly no-need to prewarm loadbalancers. And probably there aren't mystery settings that require you to email someone to ask them to be set, and there probably aren't features that you can only access through the GUI with API support coming later -- though that is just a guess :)
A downside to GCE would be if you wanted any of the various other services that AWS provides, since they provide a ton more. AWS also has really good service -- Google may also, but I haven't had direct experience.
Maybe this is preference or something changed since I used GCE daily, but I disagree on almost all these points.
* Documentation - On the surface, GCE docs always looked better to me until I realized how many mistakes there were and things out-of-date. Not to mention there was too much of the obvious documentation and not anything regarding subjects where I'd actually want detailed docs. Although Amazon's docs are trash, they have the benefit of everyone and their mother writing about how to do x, y, or z. Whether that's a benefit or not, it depends on the author.
* Console - The console was sometimes more responsive depending on the action, but for some things was worse. Overall I'd give this one to GCE as well, but I think the GUI was a mess in places. Perhaps that's more based on my total usage of Google Services, which are a superset of GCE. Regarding command line tools though, I felt these were awful, slow, poorly documented, and buggy. Again, maybe an update fixed some of this. Google has a really bad history with consoles. Amazon's GUI is 90sish at times, but it's been pretty good to me and the API just works.
* The answer to this one is really it depends on the machines, location, etc. GCE has some advantages here that are well documented, but performance of a running machine was never really a problem I faced on Amazon provided you select a good instance type.
* Can't argue here. Amazon does like to give out its share of freebies though if you are a big enough customer or paying attention to the community.
* There are a lot of blog posts about the problem is that these can be outdated and may not be using best practises.
* I mainly use the GCE console and I found it fantastic. Showing all VMs from across regions is itself a big improvement from AWS console. The project dashboard was a mess. The new beta console is better. I found Google's command line tools much more intuitive and very easy to keep up to date. They have consolidated some previously separate tools into a single gcloud utility.
IBM used to make pretty good laptops but sold the laptop part off (Lenovo)
IBM used to have a pretty decent server line or lines, though they sold a good part of the Intel stuff off (now Lenovo for the server line, but had sold off many other parts earlier, such as storage, and started using more vendors)
There were things Software Group did like Websphere, which I imagine still does good money, but why you'd actively want to seek it out over free alternatives I have no idea. They also have DB2 in database land. Software Group used to be cooler and have better resources than hardware groups, or so we thought. I have no idea how well they are doing.
They also got rid of microelectronics and who knows what else. In general, innovative parts of IBM get sold off, and they keep the services parts? Feels that way.
Their margins on services and people are not good, so they also have the reputation of restructuring/laying-off like crazy and seemingly at random, with lots of pressure on stock price.
I was there in 2001-ish when they scrapped pensions, though the thought of pensions actually existing is a novel concept today. It used to be a place where people thought they could work forever, and that is decidely no longer the case anywhere, it shows how the views of what IBM was changed rapidly over time.
They also increasingly pushed for a contractor-heavy work force for more ability to make cuts and reduce benefits.
They still do lots of storage products like SAN Volume Controller, Storwize, FlashSystems and XIV.
However they are currently focusing on cloud, for that they have Softlayer and BlueMix.
In terms of other products MQ is still pretty big, so its CICS and as you said Websphere (which I believe has a free offering?). They still have the Power business and the Z server offering. They have SPSS, Tivoli, Lotus and Rational. Then they also have GBS (Business services) and GTS (Technical services).
Obviously they also have Watson. Some of the Watson services are available on BlueMix and they're pretty good. Currently I think Watson is branching out into all sorts of new areas. Health care is a big area of interest.
They also have ETS (Emerging Technology) which does client stuff, research and the like.
There is also a fairly big IOT department (But I don't know what happens there).
To add: they recently announced an investment of $3bn over 4 years in the IoT division, which will probably be focused mostly on analytics & will somehow tie in with Watson & Bluemix, which are the strongest pieces in their portfolio at the moment. 
They also broke out an additional "Education" unit within the IoT business unit, ostensibly to compete with PTC Thingworx, and Intel+Arduino, Raspberry Pi etc. in the student/teacher/maker market. 
To add further, IBM's biggest revenue source is not technology and software, but its IT/business services & consulting wing which is no different than most IT outsourcing companies in the world. Of course their products do influence some of the work done by these.
No, IBM had defined-benefit pensions, with 401ks as supplemental. In 2000 they announced that they would do away with pensions entirely for anyone not within N years of retirement (I don't recall at this point, possibly 5 or ten years). For those "near" retirement IBM would cease paying into the pension plan but they would still received a traditional pension from the funds up until that point.
Do other companies in tech have pensions? I just never heard of that before. I guess maybe in the context of the US Post Office (how Republicans forced it to fund retirement for so many year ahead, in hopes to bankrupt it and show how government services are ineffective and broken)
Pensions in the U.S. have always been a bit of a balance sheet scam. With few exceptions companies were allowed to comingle pension assets with the companies' day to day funds with a chunk kind-of fenced off. But the pension fund was fair game if the company went bankrupt, and in the 80s a very popular corporate raider tactic was to buy a company, leverage it as much as possible, and if it went bankrupt divert as much of the pension fund as possible to paying the very managers who bankrupted the company.
Government pensions are worse in that few government entities ever set aside a truly funded pension fund, using the argument that as a continuing entity theyd always be able to top off the fund with additional tax revenues if the investment projections did not pan out. In practice no elected official will voluntarily vote to raise taxes to meet the obligations to top off oension funds, hence the slow unfolding train wreck with public pensions in Illinois.
A general failure of any defined benefit pension seems to be the dependency on the sponsoring organization as a continuing, growing, profitable entity. No accomodation for changing economics, diminished industries, or reduced workforce.
Very few companies have those "traditional" pensions any more. Most of the companies that did have them discontinued them long ago. Just google for "pension liabilities" to see why.
About the only organizations that still have them feed at the public trough. And they're having problems with funding. Here's a recent story about a state transit agency. Its pension plan is over $800 million in the hole. And that's just one agency in one state. https://www.bostonglobe.com/business/2015/10/27/pension-liab...
That may be US specific. i.e. Retirement pensions basically dont' exist in the US anymore, at least not in the software industry.
Basically most companies in the US offer some form of 401(k) with a selected amount of supported funds to choose to invest in, often with some degree of employer matching. Sometimes there are vesting requirements on employer matching. Startups are sometimes likely to not offer any matching.
Pensions are known as "Defined Benefit" programs and 401(k)s are "Defined Contribution" programs.
The difference is pretty much what it sounds like. If you had a pension, you knew exactly how much money per year you'd make in retirement (the benefits were agreed to ahead of time). With a 401(k), you know how much exactly you're contributing and how much is in 'your' account, but the value of your retirement accounts in the future is dependent solely on how much you contribute and your personal investing prowess.
As companies and public entities underfunded pensions over the past 40 years, pensions started going bankrupt or dramatically cutting contractually obligated benefits that were to be paid to retirees, so companies began switching to employee-owned plans.
Shifting the burden of investing in retirement to the employees rather than the companies has its benefits but I think we're going to see a lot more elderly poverty as the boomers retire since on average, people are terrible at investing.
Getting a bit off topic, but when we find that people's 401(k) plans are not enough to retire on, we're not going to see more elderly poverty. The elderly vote. We're going to see young taxpayers making up the difference. The move from mentions to self-directed retirement plans is essentially a wealth transfer from future workers to current corporations.
I think that seems optimistic. The elderly do vote, but they consistently vote for people who cut their benefits... Every single budget negotiation results in cuts to medicare and social security, which by definition are cutting benefits to the elderly.
I think you're right on a macro level, the tax burden is being shifted to the younger and less politically active, but based on actual legislative action, it seems defense and social issues are more important to the elderly than retirement benefits.
I believe there were also regulatory changes that made the "dramatically underfunding pensions thing more difficult. (There may have been tax changes as well which drive many things.) Pensions survived in older tech companies for a long time; the company I worked for starting in 1986 had one until its acquisition in the late 1990s. But the pension was fairly modest and it also had the various other 401(k) and stock option plans.
They aren't the same. "Pension" means defined-benefit pension. You work here for 25 years and you'll get x thousand a month in retirement. It's how retirement plans worked up until 1983 or so. 401(k) means market-based investing. You put y percentage of your paycheck aside, and the company may contribute some money, and it goes into Wall Street tax-deferred to hopefully gain value.
A lot of older tech companies used to, but pensions are gone now.
For IBM, any accrued pension remains in a managed fund until you quit/retire. Most employees had a 401k option at the same time as a pension - you pay 6% of your salary into it and the company matches half that, another 3%.
If you didn't make the pension cutoff, IBM now matches the 6% plus some more depending on what date you started. I think it comes out to something like 14% of base pay for most employees. In a 401k, the individual has much more control over investment direction, whereas with a pension you had none.
Being "efficient" at what you do at the cost of seeing the full picture, attention-deficit decision making, etc, is not a good thing.
A lot of people with positions of power think they are snap decision makers. They are snap decision makers because there's nobody to challenge those decisions, and often thinking a bit more and listening more, is a good thing.
As Herbert put it in Dune, "a mentat needs data".
I liked Bezos's requirement for a 6 page memo, and time to read it, before meetings. So many times meetings start and everyone wants to share an opinion, and people don't take time to listen.
Sure, inverted pyramid is nice. But so is understanding.
I really appreciate a good long-form article -- NYT and Salon or whatever - if it's somewhat focused. So much that passes for 'journalism' these days is reformatting quick summary feeds, and it loses meaning.
He's saying give me a memo like The Economist writes its articles. Clear. Precise. No fluff. Lots of facts pertinent to the topic at hand.
He's saying don't write like the New Yorker. Lots of backstory, lots of trivia, the overall point - if there even is one - is usually quite subtle and takes a while to pinpoint.
I'm subscribed to and read both. There was a NY article on Varoufakis ('The Greek Warrior'), easily a 45 minute read, and at some point the writer talked about how the girl in the song 'Common People' by Pulp is rumored to be Varoufakis' wife. I found that fascinating and am happy the author included that part.
Sometimes though I'm not interested in a story, and I only want information relevant to what I'm looking into at this very moment.
I was using that as somewhat of a euphimism for the leader that doesn't know anything, but likes being correct and pretending he does. He does this by saying "let's do that", or worse, "I am going to tear up your memo and humiliate you by requiring you to take a class because you're wasting my time", which is pretty deep on the ego scale to say that to someone. It might be better to just reply "I'm having a little hard time following this part about X, can you summarize this and what would you decide?" or something.
One tip that should probably be shared - Marketing that is so obvious that it's marketing doesn't work. Most firms seem to play by exactly the book in the article, and it's a little predictable. Does it work? I don't know. Maybe it does. Though I'm interested if some experimentation can remove some local maxima.
And once you are trained to spot a NPS question, yeah, it starts to rub you completely wrong. And you can tell when you are part of a email drip campaign more quickly, or when you go from being a automated plast to a warm lead or whatever.
re NPS, I do think it's useful to ask people who aren't 8's why they don't like you maybe more so than asking the 9-10s to engage more. I am also not sold of the NPS idea of only asking that 1 question - but surveys can often be constructed to only answer the known unknowns [sic] and can be misleading. Arbitrary comment boxes without leading questions I think are great.
Use it as a learning tool, not a selling tool. It is more interesting to try to make being awesome your selling tool.
Same goes for blog posts, if it's full of buzzwords with no details, and it's obviously marketing, if the buyer audience is actually technical users, those efforts are likely misapplied.