mpdehaan2

Seriously this. Salary is NOT everything, and a job that is kicking your butt all day and especially eating into weekends is not worth the tradeoffs. At least, it will catch up with you.

Salary is useful for buying things, up until a point, and at a certain point (assuming you aren't too materialistic) whether you are enjoying the job and other things gets to be way more important, and monetary compensation really doesn't make you that much happier.

Ironically, the package to make your package requirements easier to write has additional requirements not in the core distribution :)

But more seriously, good idea in thinking that things should already be this way. The dual maintainance of the dependency list between setup.py and requirements.txt unfortunately leads to a lot of packages being left out of one or the other, or a package that works great from source that has a broken setup.py (which usually applies to everything I do).

A setup.py command for installing deps from setup.py would, to me, seem a bit more logical - but things already exist the way they do.

In the end though, it's a bit weird to deviate from the standard norms of package installation, at least in Python circles, which may introduce some confusion -- contrast this with Javascript circles that replace "the one true way" about every 3 months :)

There kind of used to be acceptability for this - i.e. architects designing the class topology and sometimes even method names, and handing it down. From what I've witnessed, this started to fall out of favor around the early 2000's, if not before.

The problem (at least as I imagine it) was that this is inefficient when the designs need to change and one person gets a really soft easy job and the others get a lot of detectable grunt work.

Now we have the opposite problem - the "architect" title is kind of despised by people who know what it means, and everybody designs - but often those designs are at odds with each other, and usually too entwined with ego to come to compromises that make different sections of the code work well together.

There is a complex balance between finding the right level of top-down design and order and using all the assets of the team to make sure things are good and stable, and in particular, maintainable to folks who are going to be new to the code.

I've given perhaps 50-100 interviews and I'm not sure how many I've been on the other end of. I still believe interviewing is hard.

One of the things I typically told my employees and coworkers to do was to avoid psycho-analyzing someone based on small wordings and behaviors in responses.

Really, hiring is imperfect - I did try to hire people who were high energy, friendly, and not likely trying to suck up or B.S. through an interview - but there's a lot of things you can't really tell.

Many interview questions - such as targetted selection - can find negatives to not hire someone, but are easy to bypass if someone knows how those questions work (always give answers that cast you in a favorable light, etc) and are good at interviewing.

I agree that a lot of places do screen too much on cultural fit, but on the other hand, people want to work with people that will be good to work with - and they will have a LOT of time to spend with these people.

In days where we so closely identify with our work, I can see wanting people who could possibly become friends.

This becomes dangerous when it trends into ageism, or reduces the ability of very well qualified people to get a shot, and I've seen firsthand this result in some places hiring a lot of young folks that THOUGHT they knew a lot, but were really at a sophomoric level of experience.

Really good products come out of a diversity of experience and technical backgrounds. However, if someone is going to clash with the team, it's somewhat also better for them to not be working with that team - sometimes - but sometimes it may also work out great.

There's really not a good answer here, only tradeoffs.

People are squishy and complicated.

I tried to limit psycho-analysis and culture fit to "are these good, honest, and mostly friendly people".

I also believe smart people can learn almost anything, and often technical criteria or even small tech preferences that are not clear-cut can be used as code for really not hiring someone for culture fit.

Sometimes I feel a greater danger in interviewing is not allowing the interviewee a good enough picture of what is wrong about the company they are joining - often, interviews feel like sales pitches at the candidate, or focus primarily on the candidate's abilities and background, not hitting most of the things that will really say "will they be happy here".

Perhaps you're not technically deep enough to see other solutions.

Perhaps you are trying to disagree with a point by conflating it.

It seems like it would be easy enough to crack it open and replace the OS boot data.

That being said, I really WANT the data in this case. I hope Apple finds a compromise where they can help get this specific data without risking leaking a compromised OS.

Sometimes companies can be successful in spite of their leadership, because they have people that care about the users and products working under those conditions.

I just imagine how much BETTER those companies could be with more positive leadership though. It's a waste.

If Nest is this way under a tyrant, imagine how it really COULD be, and how many more interesting things they could create.

Absolutely not.

Python strikes an amazing balance in being a rapid development but also sustainable language, that makes for maximally maintainable code.

While I can't speak for it's growth in data science, it's widely used in systems programming and web development and web services as well.

Go is simply not as agile, it's a lower level systems tool for "tight" low-level code, yes.

Python has never been a front end language. I still think Javascript is a HORRIBLE language, but that's beside the point.

At least from my experience, it's exactly in the perfect sweet spot of language design for being unexciting and getting massive amounts of work done.

I kind of feel much adoption of "microservices" is not for technological regions but for human ones - to increase separation in architectual and code choices where just dividing work up by component wasn't enough.

So many times.

If we take the (cough) hackers and painters analogy to weird places, software is painting.

Where when if you have everybody being creative, the vision can get watered down and not as good as it could be.

Companies are the same thing, when different people have conflicting goals, and want to express their creativity, it breeds conflict.

Some conflicts and checks and balances are good, but I believe the most creativity happens when groups are small, vision is unified, and everybody's more or less on the same page.

Working with sharp people is great, but often there are multiple equivalent choices. Arguing over A and B, or compromising to do a little of both, is often way worse than going all in on A or B and then moving on to the next task.

First off: screw Silicon Valley. Using this as a label for the whole tech scene really has to stop.

Second off: I really like the patronage idea. It feels horribly unfair if you are NOT included, which is why it can't last in many places, but back around 2006 or so I joined Red Hat and we had the "Emerging Technologies Group" (now defunct).

Basically, our group was told to go make systems management applications that made people's life easier. No plan on commercailing, and we barely conferred with each other but every 6 months or so. It was pretty amazing.

Cobbler and Func came out of that, and eventually I was able to get more involved with OSS than most people do, and that led to a lot of other things later on down the line (like Ansible).

I think it's a really cool idea to just find some smart people, vaguely wave at a problem, say, "go make these users really happy" with very few parameters and see what happens.

I also believe in companies with a really strong vision of what they want to build, but what we miss is that some of our best designers are also the builders, and when we get one person designing and hundreds of people building, we can possibly get bloat and a bunch of untapped creative potential.

The theory of the 80/20 time, that I hear seems to be a myth, is a step in the right direction.

Sure, they have access to the schedule, but seldom does someone want their calendar being filled up and someone else deciding what their priorities are.

So it ends up being more about having a status symbol.

I would look at is as ok language for lightweight scripting of Java, but some areas like how bad the tracebacks are or how well many of the clojure-specific libraries are fleshed out (or quality of docs), leaves me with major concerns about the language.

I always found this somewhat amusing, encountering it enough.

Email to someone. Suggest meeting.

Someone's email, CC you: assistant, schedule this.

Email to assistant. Let me see when X is free (cc you, person).

Person's reply to everyone, you and assistant: tell so and so, let's do X at 2pm.

Assistant's email (cc you, the person you were talking to): we'll do X at 2pm.

I think somewhat the same about why travel agents are dying out, having to tell them exactly what flights you prefer and where, and how to not screw up your layover (and be able to easily reschedule when they are not around), it's usually far faster to just do it yourself.

The basics work pretty darn well from homebrew and Rust 1.5 (using the online instructions from the Rust homepage), the windows dependencies cargo is downloading aren't a blocker.

brew install sdl2 sdl2_image sdl2_gfx sdl2_mixer sdl2_net sdl2_ttf sdl_gfx sdl_mixer sdl_rtf sdl_sound sdl_ttf

Should be a good starting point for lots of people. Thanks!

Posting this right after some good suggestions for the service was given feels like this is saying it is wrong to make suggestions for GitHub because they have done good things.

This to me, itself, is wrong.

The GitHub issue tracker does need to change. While it's great for OSS that projects can get a leg up SOONER, GitHub does introduce it's own problems by having some watered down tooling in some areas.

I'm STILL at odds with how it has shifted the equation from discuss to throw code at the problem, which generates extra code review and often, angry committers when their patches are not immediately merged or unwanted, or have to be reworked.

GitHub has done some GREAT things because it has built up critical mass, but because it has gotten critical mass and has become a defacto standard, does have some obligation to keep up with demand.

This seems passive aggressive to me.

Thoughts:

Is the quality of the trend data they are selling going to go down with less users using FourSquare every day?

Or are they going to buy and sell location data from other people, possibly providing some data and analysis layer on top of it?

It was a little unclear on the article, but I'd be curious why a VC dropped $45M if they think the FourSquare checkin rate is trending to zero AND the new value is caught up in them doing something with location data, unless that location data is coming from somewhere else?

I wonder if the whole "managerless culture" is to blame and is unfixable? (In other words, why hasn't SOMEONE had this thought about issues in N years? One is they deem it not a problem, another could be that they think to optimize for the filer, and the maintainer doesn't matter, or... there's no organization at all?)

There could be (theoretically) no one to make anyone do anything, and perhaps the issue tracker is either a quagmire of a codebase or something no one wants to touch because something else is more exciting?

That's one theory.

My other theory is they spend a lot of time on scaling problems and/or GitHub enterprise (which I haven't seen) -- and don't really do features anymore.

But it does feel there is no vision for changes to GitHub (maybe they think it's "solved") and it's ceasing to evolve in noticeable ways in any direction.

Can't really be sure. But I find it interesting. Again, the core is good. It's just curious to watch it so closely and not see the needle moving in any perceptible way.

While I don't maintain Ansible anymore, +9 billion on this. GitHub is hard at scale.

GitHub is fantastic because everyone is on it, but the issue system has not improved since inception - and I felt the UI changes have actually stepped back.

We had to implement our own bot to comment on tickets that did not appear to follow a template, and I would have given a kingdom for a template that let people filter their own tickets into whether they were bugs or feature requests or doc items.

We also had a repo of common replies we copy and pasted manually (this because there was so much traffic and me replying quickly would likely tick someone off - but this too could have been eliminated mostly with a good template system). Having this built-in (maybe I could have picked a web extension) would have also been helpful.

So many hours lost that could have been features or bugfixes - and by many, I mean totally weeks, if not cumulative months.

GitHub does the world a great service, and I love it, but this would help tons.

I always got a response when I filed a ticket - ALWAYS - but a lot of them were in the "we'll take that under consideration" type vein.

I feel opening GitHub RFEs up to votes is probably not the answer to serve the maintainer side of the equation, since users outnumber maintainers, but these needs to be done and would greatly improve OSS just based on expediting velocity.

If you don't use the GitHub tracker you lose out on a lot of useful tickets. However, if you use it, you are pretty much using the most unsophisticated tracker out there.

It's good because there's a low barrier to entry, but just having a template system - a very very very basic one, would do wonders.

A final idea is that GitHub really should have a mailing list or discussion system. Google Groups sucks for moderation, and I THINK you could probably make something awesome. Think about how Trac and the Wiki were integrated, for instance, and how you could automatically hyperlink between threads and tickets. The reason I say this is often GitHub creates a "throw code at project" methodology, which is bound to upset both contributor and maintainer - when often a "how should I do this" discussion first saves work. Yet joining a Google Group is a lot of commitment for people, and they probably don't want the email. Something to think about, perhaps.

Also think about StackOverflow. It's kind of a wasteland of questions, but if there was a users-helping-users type area, it would reduce tickets that were not really bugs, but really requests for help. These take time to triage, and "please instead ask over here and join this list" causes people pain.

I love all the work to keep up site reliability, maybe I'd appreciate more/better analytics, but I totally say this wearing a GitHub octocat shirt at the moment.

I'm not sure about your businesses, but that sounds super great. (Though even 30 hours a week and a quarter of that is super great if you're happy).

But I don't think joining a startup as an employee is terrible - perhaps it's even better - you get to watch some of the wheels in the machine, without being, well, between the cogs :) There are advantages and disadvantages - if the company is young and it acts like it, it can be chaos - but you probably don't have the bureaucracy and maybe it doesn't act like it. I've seen 400 person companies that acted more like 10 person startups and 30 person startups that acted like 400 person companies. It all varies.

Join the company who's people, product, and culture make you the most happy, IMHO. The startup isn't a terrible idea as an employee, as long as you aren't doing it for the profit. And you could still do ok, but ... that's not reason to do it.

I love the idea of a bootstrapped business, and it's a shame in certain circles that's looked down upon. Getting to a place where you can build the right thing and only grow when you want to grow, and care about employees (if applicable) first and foremost is super fantastic.

If you can do this, every time, do this. The VC equation is entirely a profit model and the focus on growth causes all kinds of tradeoffs.

I think 1% to even 0.5% is pretty likely - at which price maybe you might have to accept something maybe 15-20% below market. I would love to see early developers at this stage get 2-5%, though I think that would be hard for some to push all the way through (past the CEO if applicable, board who has to sign off on the cap table and doesn't want the option pool to be too low too soon, etc).

But would it be fair if you are good and putting in that much work? Hell yes. But likely you're good, and hopefully the work/life balance isn't that lopsided either. Are you going to get it? Unlikely.

Generally, fairly accurate.

One word of warning - It would be nice if most startups became happy "CEO-on-Forbes" unicorns at round C, but not all do. I've seen a startup take a handfull of millions into Round F.

Which is of course, rather much the flunk round. And a lot of very health companies continuing to raise many small series rounds.

I think most people know this - but don't equate funding stage or amount of money raised with startup success. A better gauge would be paying customers and while you can't often get a feel for burn rate, find out as much as you can.

All being said, I've had some good educational times on slowly sinking ships too.

Sometimes the product is a little bit ahead of it's time.

Social media when it is talking about your startup is particularly hard, trying to constantly manage the perceptions is a ... huge challenge (even if you don't have any internal challenges). Founding a startup is also a good way to work 9 years worth of time in 3 years (or whatever), I sort of view them like the life-extraction machine in the Princess Bride sometimes. You are constantly trying to balance all the forces, mini-max everything, wonder about what you are not doing, and it can always feel like the wheels are falling off the whole time.

I need to write a blog post on this myself very soon. Props on talking about it more, and the general theme of having more public conversations on the subject.

No problem! I've already fixed it so that all my code is forward compatible with Python 7000, despite not knowing what any of the syntax or library changes are going to look like.

It's designed to make you watch something now and does make it harder to explore something, read reviews, and so on, or just add it to your queue than it used to.

Kind of a trend I detect with "let's overhaul what's not broken and try to streamline it and make it shiny" when it makes the overall experience somewhat worse.

Someone really wanted to push the "watch what we already have on the front page from your browser" thing, it seems.

You are saying your branch is reliable, and I'd agree, most are. There are some bad ones out there where they prefer to hide behind the system and dodge complaints, no matter how nicely brought. Basically Newman from Seinfeld is an accurate descriptor.

In my particular case, the postmaster is part of the problem, and doesn't really care too much about anything but the policy, even when it means mail is being refused delivery. The oversight office complains that this branch doesn't pick up the phones - and places where they are asked to contact you about a problem, they do not. So yeah, depends totally on the branch, but they seem to know they have immunity.

I have very good luck with UPS. And again, I think that depends on the driver/route/branch/etc.

I used to use DVD service a lot at my old address and it was great, I wouldn't attempt it right now.

It would be nice if Netflix made it easier to browse content rather than choosing what categories to display and show to you.

It can get stuck thinking your really like a genre, and the recommendation engine can penalize you too much for too many likes or dislikes.

Now that the website is a bit more focused towards streaming-on-computer it's somewhat harder to browse and prepare a queue.

It feels that some content is cheaper to stream and it wants to present that content first, and also that they don't really want you to be aware of the size of the catalog either.

Tempting to go back to DVD plan for a while, really, which I would do if the US Post Office was remotely reliable. If only there was a way to rent-stream BlueRay/DVD ISOs securely to a Netflix app, and have their whole catalog legally available and not bifurcated into streaming and non-streaming, that would be really cool.

I've had this thought quite a few times.

Basically, if you want your software to last and work on lots of platforms (particularly if it is a game you put a lot of love into), using a lot of dependencies you worry about it.

I know I've written some things - not even games, that would be a major chore to port.

But C and OpenGL APIs are still going to be there, and there's a nice feeling of quietness when it's just you, libraries you know are going to be stable, and the code, and not having to wonder "is this fully baked?" or "which one of these libs is the best".

You can almost get paralyzed in finding the ideal tools and libs to use and keeping up with all of them. Whereas if you limit yourself to just what comes with the language (and maybe a few small things) a side project can be a lot more fun.

A side project is also often about the journey, not the destination, and people can get a lot of mileage out of building incredibly complicated weird things that not many people will know are even there (I don't really know how to play Dwarf Fortress and don't play it, but the idea of the history generator, terrain generator, and so on... all that runs before you play the game strike me as great examples - the kind of thought that this is incredibly impractical and therefore must have been a ton of fun to write)>

Yeah, those could be bad. I've always seen it done with strong team leads or technical managers when they existed instead of standups. I have seen that devolve though, and I know what you mean.

I was very hands on when running meetings when I did it that way. Usually had an agenda, broke when we didn't have anything else to do, and kept on topic.