mpdehaan2

I'd disagree on the myth part. I would probably agree with it being likely there isn't a lot of data.

Much of the learning styles stuff was put forth by Felder at NCSU Engineering (my alma mater). Is there a double-blind study? IDK, but it's interesting, and it resonated.

In the informal quiz in my intro to engineering class (Dr. Richard Porter's, not Felder's), it was interesting to see how preferred learning styles (from his quiz) lined up with majors. In short, mostly it was that a large number of people had visual vs written preferences, but the one thing different for C.S. students were they almost always learned globally (i.e. almost random access, not really understanding the whole, and things then popping into place as connections build up between ideas) whereas other majors preferred seeing things step by step always building on one another.

It resonated with me in general because I'm generally lost with something until I accumulate a lot of random concepts enough to get it.

http://www4.ncsu.edu/unity/lockers/users/f/felder/public/Pap...

I think it's great people are trying to pay attention to way s people learn and how to present information.

This hit home really hard when doing docs for ansible - and I tried to present things in multiple ways (different ways of indexing, presenting big picture versus building things up, and vice versa) and in writing technical documentation and seeing bugs on understanding (and twitter complaints) on tech docs it is clear people DO learn very different on the sequential vs global axis.

I also really DO need diagrams, as large volumes of words get my lost, but strangely I produce large volumes of words and seldom any diagrams. I'm also strange in that if I take notes, I almost never read them myself, so this is perhaps why I'm so bad about learning from written text and always want to jump into code snippets. (Novels, sure, they are great). I also usually need a whiteboard as a buffer for understanding architectures visually, where I notice a lot of people don't need to draw things out, or it doesn't help them (or aren't as interested in those things?)

It's useful to present things in different ways and mix things up -- not that you have to repeat everything 4 different ways. That was what Felder was trying to get across.

(A simple example might be it is good to present a diagram next to a paragraph describing a concept.)

Slight clarification, this isn't new in Docker, you're describing "Immutable Systems". It's also not mutually exclusive with configuration management tools.

The systems management tools have been doing this a long time with baked cloud images, most prominently Packer invoking configuration-tools-of-choice for baking cloud images straight (which I'd say STILL has a wider adoption than Docker) and this can also be done inside Docker files, just like it can be done for AWS image baking.

You're still going to have some things that need to be done in runtime, especially in managing your stateful servers.

That long grooming session IS a warning sign. I recall working for one disaster where we were required to have one grooming session for us (1 hour) and then it got re-groomed the same week where we heard all the tickets again.

It should be sufficient for someone to lead and assign tickets as they come in, and for people to talk to people and reassign them as needed.

Again, if you need status on something, don't have a 2-3 hour long meeting, just ask... because when you have a long meeting and only 2 people out of, say, 8, are engaged at the same time, those other people are being very expensive and are getting bored fast.

The team's velocity is what it is - retrospectives can be boiled down to a "hey, how are things working out" that you can fit into a standard team meeting IMHO. Doesn't need it's own time slot, and this can also prevent retros turning into "throw X under the bus / CYA" type meetings. You can also get a lot of this from 1:1 conversations, and probably in greater depth in that context.

I prefer ditching standups in favor of constant communication, people should know who they need to talk to and avoid waiting for specific checkpoints.

A not-too-long team meeting once or twice a week to talk about big themes is pretty reasonable, but usually I can't even remember what is said in a standup, because much of it isn't things I need to remember.

If it's forced short, there's usually not enough data, if it's it's too long, everything gets tuned out. It's really another kind of status meeting, and I think meetings should instead produce actionable items.

I was involved in some new-office cost discussions at one point, and while I feel management likes to say open offices are about collaboration, it was really really really about furniture and space costs and employee density.

So one answer is given "up the chain" (cost/density) and another is given "down the chain" (collaboration), and that's not cool IMHO.

My feeling with open offices is that sales/marketing people like it and most developers can't concentrate. It's not an extrovert issue -- I'm pretty extroverted at times, but coding is one of those things you need to minimize distractions while doing.

Keeping it private here means private from external companies that should not have access to that data, not employees. This includes competitors, M&A targets, and investors who have not yet invested and should not have access to the books.

I do however strongly believe in tempering expectations, it's wrong to try to retain people by thinking they have more than they do.

Yep, definitely. As a really bad analogy, if you are in the ice cream business and ask a customer, they will recommend you changes in flavors, but if there was, say, a huge chance in a new kind of popsicle, they'd never tell you about that. There's also a dichotomy between the things they'll ask for and what you need to get them to stay with you, or get other users sold. You can make an existing user really really happy (which I approve of), but in doing so, you might not be expanding market. Just trying to retain them is not a good solution, but there's a balance there.

But yeah, the customer is not usually going to tell you the world takeover strategy.

I kinda wrote something about that here - http://michaeldehaan.net/post/118860078737/the-rockpaperscis...

At first read this is a pretty reasonable doc for some things to consider. I also recommend watching the linked "PEP8" YouTube presentation from PyCON: https://www.youtube.com/watch?v=wf-BqAjZb8M

From past projects, I got way more adherance-to-the-letter type patches versus "make this code pythonic and elegant" type patches, and the latter IMHO is more of the point of where things should go.

It's a bit of a long/slow talk, so if you find yourself getting bored, switch it up to 2x speed on youtube and I think many of you will like it.

My personal PEP8 ignore list was:

-pep8 -r --ignore=E501,E221,W291,W391,E302,E251,E203,W293,E231,E303,E201,E225,E261,E241 lib/ bin/

Which is quite a lot of it :)

Codebases are easier to understand when everybody's consistent within the codebase, but things need to be idiomatic well beyond PEP8 and it's easy to have a forrest vs trees scenario.

It's a good post and a good thought.

Software is a giant LEGO set with no instructions, and it takes a good mixture of how to build things and knowing what you can build.

A lot of times people want to reduce product management to "visit customers, ask what they want, make a spreadsheet", but I think it's more than that. To do it well, you have to know the possibilities the existing stack could grow into, and also what it can't easily grow into, and set a vision that is well beyond what the masses point at. And you also have to know the industry enough to know how to build things that make sense to end users.

In maybe 80% of the jobs I've had, non-technical product managers have been probably the single most powerful force to get me to leave an organization, because I always get very invested in a product and want to see it do the right thing, and I want to work on and design the right things. Working on the wrong things - features nobody is going to use, features that won't work, features that don't take advantage of a great opportunity or make a product great to use - can be demoralizing. I want to work on the thing that will make the most difference -- and then be able to witness that difference in hearing those stories from userland.

And the second you take the design out of it (and reduce software down to implementation), for me, the fun parts are gone (unless there's some heavy C.S. or architecture parts, which in CRUD stuff is rare) and it's just implementation.

Also - I will say, having done it, product management is always one of the most misdefined and potentially most disliked positions from the outside. It's the easiest to please no one while still trying incredibly hard to do the right thing, and probably the most important make or break function - because a company is totally viewed by what it decides to create. Further, a good PM can be made powerless if he can't get engineering do anything, and frequently organizational lines are set up so that he cannot. It's a position that needs to be elevated because it's so important, but instead almost gets lumped in with project management and viewed as easily interchangeable; the result is bad PMs make it hard for good PMs to get any respect. There's a huge standard deviation.

Product management can also get in a bad spot when you give a few people absolute product control, and you ignore the ideas from developers and others throughout the company. So even if you are in this spot, and it's respected, you have to give voice to the entire company and try to focus sometimes hundreds of laser beams all pointed in different directions.

The C.S. I majored in was about designing things, a lot of software engineering is about implementing features out of canned components other people have already designed. I think there's a lot of lost possibility in that, and we should encourage everyone to be more creative and blur the lines more in how we define software positions.

Some parts of companies can be corporate and still have some other very good parts.

All being said, if at that stage of a job offer, you don't want to be looking like the most important thing to you are your options. If you get a decent salary and like the work, you are not being exploited.

Err, no. Not always.

If a "rank and file" developer goes back and forth grilling them over offer terms, and is exceptionally picky above his peer group, this DOES make it back upstream in negative ways.

Some companies will not give you this as a matter of policy - , if you are ok with the salary, you could still enjoy working there - and may also make a great deal of money (or you might not).

It's quite valid and exists as a reason, you just don't agree with it :)

I don't know of any examples, it just seems like it would be a good way to structure things. I also can't see it being bad if it did not differentiate by position - I've heard a lot about how much, say, enterprise sales pays itself (because effectively it sees the money first and controls who sees the money) and I'd be very wanting to make sure everyone - admin assistants, everyone, who made the organization great had a chance.

I think you would want to calculate a % early in the year, and then award that percentage at the end of the year.

If you wanted to taper that somewhat by employee reviews I guess you could, but it shouldn't be on quota - and ideally you'd just not continue to employ those people you didn't want to be there.

Yes, everybody would lose out if there were no profits. And a lot of startups aren't profitable. But (IMHO) I think that's also where SV investment gets it wrong -- they value growth above profitability sometimes, and this desire for rapid scaling makes or breaks companies, when in the end, I think a greater percentage could be BOTH happy and moderately successful at the same time, rather trying to bust themselves and "go big or go home".

This model is probably a LOT easier to adopt in a bootstrapped company, where there's less likely a board to say no to it -- and yeah, if you're not profitable, you wouldn't do it... and you also would be unlikely to have stock anyway.

Reasons exist.... One reason is likely that they want to keep the valuation confidential outside of the company (people talk), because as a private company that information doesn't have to be public. It's not a great reason for the employees - but it's there, nonetheless.

It's tricky to share that with employees and not have it get out.

That being said, if it were all public, I think that would be fine, I'm not sure what results that would cause if every company did that, and it might be cool if every company were required to by law (hint, hint, congress!).

Righto, and asking a lot of demands/questions means the company is not going to like you as much and will influence your relationship after the offer is accepted. The info you get will be standard and there is certain info they are not going to want to share.

Basically a casual ask for "can you share how many options are outstanding?" is about as good as you are going to get. Totally good. Non-stand demands? Not so good.

If the VC has preferential shares (they do) just realize that's ok - and probably fair. Don't join the company if you don't think it can exit above it's funding amounts if you are in for the stock - but hopefully you're in it because you really will love the position and the stock is just a bonus if it makes it.

That's the most important thing :) You don't want to be in a job you don't like just because it's profitable IMHO.

Issuing 10,000 options and not telling you how many options are outstanding is very very common for startups, unfortunately. I don't know how many times I've joined companies that listed 10,000 options and I was too dumb to question it.

In many cases, it's because they don't want non-executive employees to be able to know certain financial details, including the valuation of the company. I wish this wasn't the case, but the reasons for it seem logical and in fact fair - it's just that many people assume this is a lot when it probably isn't.

The downside is many people are apt to accept, thinking 10,000 in options is a "lot", and I've made that mistake in the past. In an A round startup, this number could easily be in the several millions of shares outstanding, and likely is. If it's gone through several funding rounds, it's likely even less. 10,000 in a C round is significantly less if they have divided the stock by 10x or more in the previous rounds.

Executives could be pulling in whole percentages of the company, or multiples thereof, and one of the first few members of technical staff could basically be looking at a year's salary or less in payout if the company would sell in 5-8 years.

The percentage of the companys that make it is also a factor. While the article focused on needing to stay at a company, it's fair to consider that the great majority of startups are going to fail or be very small acquisitions (asset deals, acqui-hiring, etc). In these positions, the VCs will get paid first, and there may not be much if anything left.

Another possibility is the company is sold for small prices but the CEO could secure a very very nice deal to join the new company (plus bonuses), which has happened on more than one occasion.

A VC only needs a small fraction of his portfolio to do big exits, so they make lots of bets.

Stock is a huge gamble. I don't recommend "no stock, just cash", but don't ever let someone underpay you on hopes the stock event will happen.

Stock is being used as a retention tool, and that's the design of it, unfortunately.

I'd be much more in favor of equitable profit sharing as a retention tool - suppose a company decides to give away X% of it's profits back to employees forever, and this is done in a way where it isn't the CEO/leaders making all the money. Instead say in a 50 person company, 10% of the profits always go back to the people, and each person gets 1/50th.

This also eliminates sales commission on large deals and makes everyone part of the deal (the whole company) profits - also no quarterly targets, personal bonus tiers, executive bonuses, or anything like that. As the company becomes more efficient, those numbers go up, and it keeps things simple.

What I meant here is that you go to the boot camp and then they (what I've been told) assign you to a group.

I don't know how much preference you can have.

As such, I think it's possibly very similar, though I thought with Google you did get to apply for specific groups.

That is pretty neat and I love seeing more project statistics- however, fair warning, I was a bit surprised it doesn't scan issues older than 6 months.

As a result, if a project closes all issues in either a day or ten years, it will report that the mean time to resolution is 1 day and not essentially ten years :)

Yeah contributing.md doesn't get read much, or it gets skimmed over.

Issue templates seem to MOSTLY fix the problem, so we wrote a bot that sticks in some canned questions when it looks like your bug didn't follow the template. People recoiled to the bot for months but new users were totally fine with it.

I really wish GitHub had some sort of optional facility for a stock template for the "bug" field, as it would save collective years of people's combined lives. It would just need to populate some text in the issue box by default. Call this ISSUE_TEMPLATE.md if you want, etc.

Various third party attempts to do this - like use this bug page instead of github's new issue form, don't really work as the one NICE thing about github is that everyone knows how every project sort of works. Sort of. Which is also the one nice thing as they don't join the lists or really understand how various projects really really work :)

+Lots to wanting to help heavy contributors first.

While there are a lot of "hey free software" people who don't contribute back, I love those non-contributor companies when they pay actual money for something. My experience is those are usually very reasonable with time-table on fixes and understanding, and the business relationship adds value. Maybe this is more about the maturity level of the company you are likely to be working with, I don't know.

If someone is however just a user, though, often they feel obligated to get infinite value rather than just the value they are paying :)

Amen...

I totally got the second job feeling.

I mean I love all the contributors - I do, but a few nights a week is fun, all of them is bad, when it starts to eat your Saturday, that's a steamroller.

There's reward, yes, but mostly there's a lot of people who (queue up the Sixth Sense voice) that WANT THINGS. I mean, everybody totally means well, they do... but so many people wanting so many things.

You could spent all your time just helping people who didn't read the docs, helping misunderstandings, restating the obvious, code review, website editing, so many things. And you have no time to do them all flawlessly, so you do them all the best you can, and get hammered on the things you couldn't be perfect on. Then you get into Catch-22 scenarios as the project grows and must please conflicting audiences.

Open source is really really really hard.

I think ones with very focused audiences (say, like, insect biology?) may have it easier - the more general purpose you are, the greater the demands from diverse audiences.

Programming languages may have it the hardest, I don't know.

Given, most people will probably think I succeeded at all of those things, but it also broke me in ways that would make me reconsider doing it that way again. Maybe everybody has energy to do it some, but ... it's rough.

There's so much more to it than just writing code too.

It's completely accurate - hence the location part. If you sought to add clarification, the first sentence was unneccessary. Let's confine this to "they won't hire in most of the Continental United States". Even for exceptional candidates, remote is also completely out of the question for them. That's obviously their right and I don't hold them against them. (But it's worth contrasting with someone like Red Hat, who will hire someone from anywhere if they are awesome).

I have had lots of experience with Google and Amazon recruiters where CA was the only viable option. Google also tended to have a bad habit of offering SRE positions for datacenters in the sticks, but that was not a development-flavored SRE thing in the least. They pretty much close the door on you if you don't want to move and are dropping the ball on some pretty awesome development centers IMHO.

Facebook is often avoided by some very sharp kernel (and other) folks, because they greatly insist on a boot camp and can't guarantee what department you are going to work for. They lost some brilliant folks as a result. I wouldn't work for them for that reason, as I think the team and the manager are the most important parts of the hiring decision.

Yes, Google has other offices, but they are not hiring people in some pretty darn major development regions. There is allegeldy an office in Chapel Hill for instance, but it seems to be on the edge of being decomissioned and no recruiter will tell you anything about it.

So, yeah, it's not quite like you can just work anywhere.

Well, there's really no corresponding data for many other markets . Facebook and Google don't really do Work From Home and don't have a lot of remote locations for development depending on where you are. (Amazon is another example). I don't know what they offer datacenter staff, but in many areas, recruiters are pretty adamant about people moving.

From my experience, say, the North Carolina scene, you're lucky if you are going to get $120-ish with ten years of experience. There's some give or take, but includes large companies and banks. You can do a little better at something like a Cisco if you are willing to trade quality of work. Most big companies as well as startups are paying new grads somewhere in the low-high 60s or maybe 50s depending on where. I don't have hard data, but it's no where near $130k.

Data from cost of living comparison sites that some companies use indicates that these companies hiring someone in the bay area may pay those people 20% more for cost of living at most.

Startups pay substantially less on average, with senior level personnel getting around $100k, maybe $120k if you're excellent and the startup is well funded - but this is 10 years of experience kind of stuff. I have unfortunately had to turn down some great folks because they wanted north of that - and they were worth it. I've also seen companies where their maximum pay tier tops out at 135 for what amounts to principle engineer level positions. (I'd assume a fellow at IBM would do better, but they are uncommon and few have a chance of surviving the machine to get there).

Conversely, really senior level software development positions at basically-exit-ready startups in CA aren't going to be much better than 40-50% better than the above. Some of these can be obtained remotely - sometimes.

What the article states as common for Google and Facebook are absolutely not the norm, and I'm not really sure how achievable that is for most people even there.

It's great if Google/Facebook can allow to pay people that, definitely. I just wouldn't say it's even remotely common and does not translate.

I've heard some ancedotal completely crazy numbers from hedge funds that most people would hate working for elsewhere, but nothing nearing the numbers in this article.

I don't really have hard data on the New York software scene or Texas, but .. again, this isn't normal. HN may be more of a microcosm than expected if most people do feel this is normal.

To put it in perspective, this is still amazingly high compared to a lot of other positions and you'd still have it really good.

People understand the straits newspapers are in, so it shouldn't impact your job search negatively. Still, the advice to look now helps - it's easier to say this is why you are looking - because your company is in hard straights, than if you say you were already let go. Not a game ender though.

I believe we all underestimate our own skills, but there's a lot of folks looking for generalists. I don't believe in "full stack" development quite so much, but there are a lot of people looking for it.

Anyway, 30 is a great age - You're just at the point where you are starting to be very marketable and your experience has built up to a value where you can command a lot more value based on having had the experience of all the things you have done before.

> then go on saying that it's bad for humans at the levels found in cigarettes or e-liquids

Is it bad to jump to conclusions that it's safe and everybody else should be happy inhaling your exhaust believing so?

What someone does in their own homes is fine, though this thread was discussing vaping-exhaust being fine in public, and I don't believe people have that right.

Smoking was predominent in restaurants and public areas a while back and we thought it would be impossible to go away, and now that it has, it's been absolutely fantastic.

This is basically just a "safer", not "safe" method that still affects people in a given area.

I'd rather people just use patches or something else rather than vaping down the street, in malls, or sidewalks. This would be completely fine - mind you - that it is likely to have very negative health consequences to those people.

There is no crusade. However, most people who are vaping into public airspace are in fact using nicotine with a very high degree of correlation -- this is not something many people do just to taste 0-nicotine air flavors. This started off by saying "vaping is probably safe, because similar things are used for special effects at concerts". In this case, there is at least one factor not included in those concerts - the drug most people are obtaining through vaping.

They say "this is safe", while ingesting a particularly evil toxin that is lethal in very small quantities (like a drop or two will make you violently sick). Yes, there are other toxins, but ... again, this is perfectly avoidable and nobody has any business making others who do not choose to be exposed to it.

People should have the right to not come in contact with that.

Left for the same reasons - it was interferring with my photography. Around the same time, other services like Smugmug and Zenfolio got better (I think Smugmug is now a little more up to date than ZF's look, but not originally).

Flickr decided for a long time to not prioritize the best photo display possible and limited photo size and wouldn't offer things like black backgrounds.

And now I may get an infinite less number views, I don't have to deal with the comments, and photography is no longer associated with gamification (when do I post this for the most views to hit explore, etc).

Flickr has a bit of a "look" to what is popular, and while I'm big on good photo processing and the history of the dark room, what makes it today is often too processed, too HDR, and so on, and playing the "game" is not something I'm interested in.

In the early days of Flickr, people DID look more at all the photos in groups they posted to, and that was pretty great.

Getting more people into photography is great though - just shouldn't be about numbers.

Did the goalposts not move first with the implied argument that "we ingest this all the time, ergo these things are safe?". They aren't containing just those chemicals.

I'm saying I don't want to breathe any of it I don't have to second hand, and the argument that I breathe liquid smoke at concerts or Christmas festivals is beside the point.

Forget addiction in users who decide to smoke it, nictotine a neurotoxin and exhaling it to people who don't want it in public places is inconsiderate.

There's a logical fallacy here somewhere.

I'm sure stage smoke isn't also a viable insecticide.

Growing up around people in the tobacco industry I know nicotine is lethal and easily absorbed through the skin, and not something you want to be around if you don't have to -- and especially not if someone has breathing problems.

The long term consumption data will take a while to build up about all the health effects. It's not a good idea to be a guinea pig for that.

Yes, I'm aware it's not an ORM. It's pretty primative by comparison and I wanted a good Clojure ORM at the time.