Because lots of programmers loves to talk about code?
> A shared niche interest is not sufficient basis for a good relationship.
Then what is a good basis for a relationship? A shared interest in ubiquitous interests like food, blockbusters or travel? I don't think that is much better.
> I’m a woman in tech and I don’t necessarily wanna talk code on a first or second date, I’ve got professional development figured out on my own time.
Good for you, not everyone feels like that though.
The presumption was that it's sexist to assume you can't talk code with young women. I don't want to talk code with anyone 99% of my off time. But to say the reasoning is sexist is untrue.
This is such a good point. Take SQL. It has survived because it is well designed, and changes so little and so slowly, and it’s obvious what SQL is and isn’t meant for. Amateur programmers can port SQL queries between database systems semi-painlessly. In the right environment a query can survive with small edits for YEARS.
That's something of an illusion. The flaws in SQL often aren't noticed because you usually pick one database vendor and stick with them. There are plenty of differences between vendors, but you don't usually have to support them at the same time, and you don't notice for simple cases.
But changing database vendors for a company can be a big deal, as bad as going from Python 2 to 3.
This is true. But, I think he means syntactically you can make jumps from one dbms to another without much of a fuss. Obviously there are non-language features but, that is not what is being discussed here.
That's mostly a result of databases (kinda) converging, SQL being a declarative language and it primarily being a wrapper around relational algebra, with a bunch of flags. And of course, it's a very direct interface to the RDBMS, and you're just migrating between systems that try very hard to have the same interface.
As a language however, it's a whole lot of nonsense. Extremely inconsistent syntax, stuffing a trinary logic into a boolean system, a standard that gets extended arbitrarily, and even the tooling ecosystem is a fair bit pathetic (the lack of formatters particularly annoy me; everyone tries to support SQLs generally, and end up missing every extended feature.. if it's not a simple select query/ddl, you're not getting a decent format output)
And it most certainly is a whole lot of fuss to migrate unless your database is tiny, or you didn't actually utilize the DB except as a dumb datastore (eg you relied solely on your ORM + indexes); there's a reason no good translator exists, and those that exist only support a very limited subset of any particular SQL variant, despite programming languages having a whole array of transpilers; it's simply not at all a simple language, and the variants only superficially look the same.
"As a language however, it's a whole lot of nonsense. Extremely inconsistent syntax, stuffing a trinary logic into a boolean system, a standard that gets extended arbitrarily, and even the tooling ecosystem is a fair bit pathetic (the lack of formatters particularly annoy me; everyone tries to support SQLs generally, and end up missing every extended feature.. if it's not a simple select query/ddl, you're not getting a decent format output)"
Would love to see your point in action. For me personally, speaking strictly writing simple scripts, they pretty much translate fairly well. Regarding formatting, are you referring to the output?
Every couple of months there's a new startup / dev site that says "SQL is broken/old/bad, so we reinvented it!". They all sink without trace, but there's a cohort who agrees with them.
Agree totally. I had to climb the painful learning curve of psql because none of the front ends worked the way I wanted for some reason or another. Of course, having learned psql, I'm now scathing of anyone wanting a front end... hmm... maybe that's why ;)
I was actually thinking about the lack of SQL alternatives using the postgres engine; for example, why is datalog not simply available as an extension? Or MySQL syntax? PG implements a wide array of alternatives to PL/pgSQL (including standard programming languages eg python), but for whatever reason these SQL-alts never seem to consider being layered on top of the postgres engine.
However, the lack of GUI frontends is also really weird. I don't see why it'd be harder to support than any other DB, and afaik pg has gotten fairly popular..
Sorry to be that one avoids-the-question comment, but:
Without design sessions to figure out your data store design (look up Kimball, Immon), and then monitoring/testing to make sure everything is running smoothly, any data stack will be hell.
Badly designed data brings fatigue and rancor and unnecessary work and is a huge hard-to-quantify money suck.
IMO the right solution to this is not spending a bunch of time upfront trying to design your warehouse. You just want to adopt a tool that makes it easy to continuously refactor into more optimal formats as your warehouse scales. Happy to discuss more if you're interested! dan at dataform.co
At some companies you can get a negative performance review for not being on Slack during working hours. “Needs to be more responsive / better team player.” In other places you might be expected to be online beyond 9-5 too.
It's difficult but I'd avoid places like that. If your team won't allow you to close slack for an hour you have serious communication and planning problems. Anywhere I've worked what I do is message anyone who might need vital information from me then just close slack for an hour, do my work and check back in. When I get pulled up on it I give my explanation about focus, communication etc. If they don't like it then I leave. I'm glad it's a seller's market.
I’m just as curious about how the managers were trained to be process-driven. Manager behavior seems to me just as if not more important than IC behavior here.
Since managers have power, and engineers usually don’t personally know their skip levels, managers can easily replace async documented process with lovely hours-long face-to-face 20-person meetings. And they can silence dissent! They can wreak havoc in a way no IC could ever do.
> replace async documented process with lovely hours-long face-to-face 20-person meetings.
This has been a particular pain-point for me at times. Example: two meetings with the same team members on two connected subjects of about 45mins to an hour in length, spaced half an hour apart when they could easily be combined. That's just in one day. There are others that have mirrored those throughout a week. The meetings don't need to be as long as they are, but they're scheduled for that long and the rest of the time is often filled with awkward chit-chat. But it fills the manager's calendar slots so that they appear effective, even if a lot of time is being squandered. Add on all the frustration of the back and forth across floors, wandering the halls looking for a meeting room that isn't double-booked or waiting on people to vacate rooms, etc etc.
IC time is more directly controlled this way. Occasionally it makes sense, but the amount of duplication is, at times, staggering and can be frustrating.
We had a client one place I worked that liked to schedule 1-2hr meetings, never bring up the topic at hand, and then the three or four folks from their company would just chat things through on the phone with one another, mostly unrelated to anything we could conceivable influence or care about, while we sat there twiddling our thumbs. This was probably a majority of their irregularly scheduled meetings. One or more of us would get roped into one of these every week or two. A couple of their folks also liked to schedule 30min calls with 3-4 people in response to Slack questions that should have been answerable in under 5min (total time spent, not necessarily within 5min, not everyone's always ready to respond on Slack at the drop of a hat) with no phone call. I strongly suspect they had a culture that rewarded their middle managers for having calendars full of meetings, with no regard whatsoever for whether the meetings accomplished anything.
I'd love to hear from managers and others who saw compensation increases from having their meeting calenders arificially full, and not from what that managers got from those meetings.
Has anyone ever promoted a manager because they have so many meetings?
The only point I'd disagree with is "these days". Overmanagement is the perennial problem in my experience. More do'ers less say'ers is my proposed solution.
I totally agree with you. I like all-remote teams. I’m wary of teams that are part remote and part collocated, especially when the leaders are part of Team Collocated and I’m not.
- A shared niche interest is not sufficient basis for a good relationship.
- I’m a woman in tech and I don’t necessarily wanna talk code on a first or second date, I’ve got professional development figured out on my own time.