"A lot of times the concerts weren’t sold out at all, but we pretended it was. It was just a lie. Pretty much 100% of our traffic came in through AdWords, people would search “Something-something concerts tickets”, got an ad from us, and be duped in to buying them at ridiculous prices."
> At one point I learned that one company we connected with would literally just invent concerts: they would guess “they’re probably doing a tour next year” and start “pre-selling” tickets for it at extraordinary prices.
“I very much regret working on this First job, insecure about your career prospects and whether you’re able to get a new job, and it becomes easy to rationalize these things to yourself.”
The scam works because they put you under time pressure and the refund laws for internet purchases have an exception for concerts/events. So you think it is almost sold out and you can just get your 2 tickets you want for 200 bucks, you order, afterwards you realize... Wait a minute... There are official sellers... but that's it, you have to pay.
It's not hard. I use git add ., git commit -m "asdfghj", git push as my save. Exactly like I press Cmd+S in Photoshop all the time. So naturally I end up with a ridiculous amount of commits.
My principle has always been "commit early, commit often" and "push early, push often". This works well when you do your work in a branch and you only "squash and merge" into the main branch (even if you are the sole developer on the project).
Works extremely well indeed. Like git was basically made to be used like this. However, only because of that 'squash and merge' aka 'sculpt a nice history with the emphasis on story' bit. Not doing that is in my opinion and experience completely useless for code. As far as I'm concerned there's hardly any difference between one commit with message 'fixes' introducing a 1k loc diff code dump or 1000 commits introducing a one-line diff: a proper git history is a joy to work with when figuring out bugs and why/how things were done the way they are. Anything else is just mediocre at best, usually just worthless. Which I learned the hard way obviously.
> However, only because of that 'squash and merge' aka 'sculpt a nice history with the emphasis on story' bit. Not doing that is in my opinion and experience completely useless for code.
A thousand times this, I use `git log` as a debugging and learning tool, if I can find the exact commit that introduced a change that I don't really understand why or how was done I resort to looking into git's history to figure it out.
I hate when developers don't put an effort to tell the story of "why" you are doing what you did. The most common failure is just listing down the changes done in the code (the ones you can just read with `git diff`), I hate that.
I treat git's history as a breadcrumb trail, I leave as many breadcrumbs as I can on my commits so others can find the trail later on: JIRA ticket reference, background of the change, why a refactoring is being done, what I found during the refactoring that made it end with a strange design, why the documentation needed to be edited, etc. Whatever I can think that would make my life easier in 1-2 years time if I ever had to read `git log` I try to leave for my future colleagues...
The most common failure is just listing down the changes done in the code (the ones you can just read with `git diff`), I hate that
Exactly. But I have noticed for some people this seems just really hard, don't know why exactly. Even after repeating and explaining the same thing (git commits, just like comments in code, should explain why, not what, the what can be inferred from the code and if not the code is usually not very good) I see people struggling with coming up with an acceptable explanation in full sentences of why a change was made.
This reminds me of when I joined a company that used Dropbox for deployments. Install and configure Dropbox on each server, drop your updated files into Dropbox on your local computer, and boom — deployed. (Sometimes.)
I am working with a client today, in 2021, that still has multiple developers making live changes to a dev server as part of their everyday development process.
Some of them make their changes locally in VS Code (or Notepad), FTP the changed files to their home directory, then sudo cp to replace the existing files. Others SSH into the server and directly edit files using vi.
Due to that workflow, none of those devs ever use a proper debugger (and have committed a lot of random console logging) and there are often conflicts when more than one person is working on a file. To address that, there is a Slack channel dedicated entirely to announcing what file you are working on.
Just use "git commit --amend --allow-empty", no need to change anything!
Edit: this is mixing up two things, what you want in this case is "git commit --amend -C HEAD && git push -f", i.e. replace the current commit with a new hash and force push.
Alternatively you can create an empty commit as above, but that isn't amending.
> No one liked how any of this worked, but just accepted it as a fact of life, like how you would accept that it really sucks that it rains today. That’s an attitude I’ve seen more often and never really understood: if I see something that’s really awkward, frustrating, and time-consuming then I want to fix it, but a lot of people seem happy to just and accept it.
I think it’s more like « this place is full of smart people that knows this is shit so if nobody fixed it already, it must be hard to fix ».
And since this is a shared behavior, even your potential fix can be hard to get reviewed because everyone will be afraid of the potential side effects because nobody understands why it even worked like this.
Seems like an issue on Heroku's end really, maybe some build dependency timeout which is then cached or something. At any rate, I'd either dig in or contact Heroku, I couldn't imagine leaving that lie without knowing the cause.
Often, the root cause of this will bite you hardest when you need it least.
> And if stuff is awkward then … maybe you’re doing it wrong? No one liked how any of this worked, but just accepted it as a fact of life, like how you would accept that it really sucks that it rains today. That’s an attitude I’ve seen more often and never really understood: if I see something that’s really awkward, frustrating, and time-consuming then I want to fix it, but a lot of people seem happy to just and accept it.
I won’t lie, I keep using commits as the equivalent to saving, and hence have many commits on my GitHub Profile (2,000 in the last year - many for me, I guess some have much more).
At some point I got addicted to the number, so from time to time I try to manually increase my frequency of commits.
All that said, I end up doing more commits when working on front end stuff, when I doing back end programming, I am not at all interested in saving / committing frequently as I’m focused on the task at hand. With front end stuff, you necessarily need to save and refresh the webpage in your development browser, so it goes hand in hand with increasing my commits :-)
Do you use `git stash`? I don't understand your workflow, do you commit to keep a log of your whole line of thought? As in: with your mistakes or failed designs/approaches being backtracked (overwritten/removed, etc.) and keeping an immutable sequence of your line of reasoning?
For me, commits of work in progress are only done on my development branches before I want to push to a remote to save my work in case of my computer failing (or getting lost/stolen, whatever force majeure), I usually write a "WIP: <what's been worked on>" message that I will squash later on when I have a meaningful commit.
You can commit every single character if you in the mood. At the end, when your new feature is complete, you just squash all commits in this branch to one single commit ("add feature xyz") and merge/rebase it to your main dev branch.
Now it is really easy to identify the actual code behind a new feature.
This is a good opportunity for me to ask something I've been wondering for a while about what is appropriate to put on a blog tied to your real identity.
The majority of this article could be seen as negative toward the author's former employer. The website is also listed on the author's CV, and knowing the author's name it is easy to find the website. Is there the possibility that this is seen as unprofessional, or that someone who was involved might read it and be upset? Maybe it is okay because the company is defunct (I assume), or because it was so long ago?
I ask because I am early in my career and I just finished a job where the majority of the things I learned were non-technical in nature. I would like to write about the lessons learned but, like this article, it would have some component of criticism about the company. Like the author, my website is on my resume and the website can be found by searching online for my name. Someone reading my resume could figure out what company I'm talking about, and some people who work there might find it. I don't live in a large tech hub in the US so it's very likely a future potential employer knows some people personally that I might have criticized vaguely (but due to process of elimination from the jobs listed on my resume wouldn't be hard to identify).
The advice I've been given from people I know is to either not have a website tied to your identity at all, or be as professional as possible if it is tied to your identity.
What do you think? If you knew this author, or it you stumbled across this article because you are thinking of hiring the author, how would you feel?
I personally wouldn't, but everybody has to decide for themselves.
I at least know a few companies that would avoid hiring people who criticize old employers, afraid they will be next. I mean, most companies have at least some "skeletons in the closet" of bad practices or what not.
Having said that I'm usually brutally honest in job interviews, I see it as my way of screening companies, if they don't want the honest me, then I would probably not fit the company culture anyway. So there might be nothing wrong with having an honest blog in the end, maybe you receive less offers, but the offers match you more.
I would imagine that the how makes a big difference. Publicly on a blog vs privately in an interview is one aspect of that. And your tone: matter of factly stating problems vs agitated ranting.
I think this is a good question; as the author of this, my general attitude to these kind of things is that I'd rather just be myself rather than try to tactically modify my behaviour to get better outcomes.
I've seen people advise that you should "avoid controversial topics" on first dates, as that "might be a turn-off". Well, maybe it can be (certainly had a few dates like that), but that would also be boring conversation, and not very meaningful as such if you're actually looking for a serious relationship (which doesn't apply to just romantic relationships by the way, also other kind of social relationships). Related comment from last year: https://news.ycombinator.com/item?id=23788380
It's partly cultural as well; I've seen this in certain countries (cough England cough), where everyone avoids talking about anything meaningful so all they talk about is the weather or some such pointless conversation because they're afraid someone could possible disagree with something they say. It's not like I'm against small-talk, but if that's all you do... Okay, I'm exaggerating a little bit, but it's certainly very different from my own Dutch culture where people tend to be a lot more forthright.
It's not like I will just say whatever without any filter or consideration for other people's feelings, or what might be inappropriate, or without being receptive to feedback. Actually, I try to be quite conscious in how I communicate, especially online where the lack of body language and diversity of culture/social norms can make things pretty darn hard. But at the end of the day this is mostly about how you say something rather than what you say. e.g. "this is stupid" vs. "I'm not sure if this is a good idea".
There are always trade-offs of course. I was known as "Carpetsmoker" online for years and I changed it across the board over a period of a few years to "arp242" mostly because I felt "Carpetsmoker" didn't sound too professional (a lot of people seem to associate it with drug use – I don't even like to smoke cannabis! It was just a funny joke I made when I was 14 that turned in to a nickname). I still think it's kinda funny, but what's an appropriate nickname when you were 14 isn't necessarily appropriate when you're 36 and actually use your GitHub as a way to earn your living, and it doesn't really matter all that much what your name is; so I just changed it.
I publish it on my personal name because I see it as my personal space. Being anonymous would make it "arp242's personal space" rather than "Martin's personal space". I know some people like to keep their "online identity" more separate from their "real life identity", but personally I don't really separate things out all that much.
This is a bit rambly maybe; I'm having a hard time to articulate my feelings on this ... but I hope it makes sense.
And, of course, everyone can make their own choices in this.
> One of their websites was a “website builder”, like Geocities, except worse. The value for the customers was that was in Dutch, with Dutch support (it didn’t even support English.[2] Shortly before I joined they decided to rewrite it from scratch (which in this case was probably the right decision by the way).
Or people just want to do the work in their mother tongue instead of a foreign language. Personally, it's quite disappointing to the see Englishification of The Netherlands. Even been to restaurants were I couldn't even speak in Dutch in Amsterdam and had to order in English. Bloody ridiculous. I don't think you will see that happen in London.
Depending on the kind of work I prefer to do things in Dutch, English or German. Anything mathematics is something I prefer to read about in Dutch, while some social science or anthropology related subjects I prefer to read in German.
I don't think the article is dismissing the value of internationalization. As the endnote says:
> People often seem dismissive of that value i18n, “everyone speaks English” Well, depends on who your customer base is. Even in the Netherlands where almost everyone speaks some English there are still loads of people who are not especially good at it and much more comfortable with Dutch. This is probably over half the population, and it’s really not just old people.
Here in Amsterdam there's probably more people who don't speak Dutch than there are people who don't speak English.
Heck, I've worked at companies where over 50% of the employees did not speak Dutch at all.
So English will reach a wider audience in Amsterdam, ironically. Not sure how well this applies to the rest of the Netherlands (especially outside Randstad).
I think you completely misread what I wrote; the entire point was that it being in Dutch was valuable (in spite of being a very mediocre to crappy product in every other way).
I always though it was strange than Dutch completely embrace English in Netherlands but Flemish make everything they can to not speak French in Belgium. We can wonder if dutch will be spoken only in Belgium at some point in the future.
> One of the developers could not code at all. ... Nice guy though; he was a lot of fun. Just a bad choice of careers (or maybe not, since his salary was a lot higher than mine…)
I've known a few people like this. One guy told me he realized programming wasn't for him after he'd been out in the real world for a year or so, but it just paid so much he didn't know what to do. I know another guy who just goes job to job and lasts about 6 months to a year before getting axed. He's able to do it because there's just so much demand in the market.
This is a truly bizarre article. The practice he is outlining here is wild, no reasonable company would do this. Lots of companies however end up with bizarre and dumb build systems for reasons of history, but this one is the strangest I have ever heard of. Even just reading the article I cannot really come away with a sense of how or why they did this and it is so strange that my brain doesn't wanna accept that it existed.
However, it's also bizarre because it seems to not just contain an explanation of this weird tech but a lot of vitriol. This guy seems to have outlined what was a dysfunctional place where a lot of junior people got a nice start to their career. This doesn't seem to me to be a good reason to badmouth the place. You as a senior engineer should be helping people to be better coders, not shitting on them for being junior developers. (And yes the owner was bad but that's no reason to shit on the juniors!)
I think if I were interviewing this guy and saw this piece I would immediately slam then Strong No Hire button.
58 comments
[ 3.1 ms ] story [ 78.5 ms ] threadSounds very scummy.
> At one point I learned that one company we connected with would literally just invent concerts: they would guess “they’re probably doing a tour next year” and start “pre-selling” tickets for it at extraordinary prices.
“I very much regret working on this First job, insecure about your career prospects and whether you’re able to get a new job, and it becomes easy to rationalize these things to yourself.”
Let's hope karma exists.
Welcome to the machine!
A thousand times this, I use `git log` as a debugging and learning tool, if I can find the exact commit that introduced a change that I don't really understand why or how was done I resort to looking into git's history to figure it out.
I hate when developers don't put an effort to tell the story of "why" you are doing what you did. The most common failure is just listing down the changes done in the code (the ones you can just read with `git diff`), I hate that.
I treat git's history as a breadcrumb trail, I leave as many breadcrumbs as I can on my commits so others can find the trail later on: JIRA ticket reference, background of the change, why a refactoring is being done, what I found during the refactoring that made it end with a strange design, why the documentation needed to be edited, etc. Whatever I can think that would make my life easier in 1-2 years time if I ever had to read `git log` I try to leave for my future colleagues...
Exactly. But I have noticed for some people this seems just really hard, don't know why exactly. Even after repeating and explaining the same thing (git commits, just like comments in code, should explain why, not what, the what can be inferred from the code and if not the code is usually not very good) I see people struggling with coming up with an acceptable explanation in full sentences of why a change was made.
git commit --amend --allow-empty
[1] To be precise, it allows to create a commit that has the same tree as the parent commit.
https://git-scm.com/docs/git-commit#Documentation/git-commit...
Yep, that one! That's the one that cracked me up, waking my wife from her afternoon nap :).
Some of them make their changes locally in VS Code (or Notepad), FTP the changed files to their home directory, then sudo cp to replace the existing files. Others SSH into the server and directly edit files using vi.
Due to that workflow, none of those devs ever use a proper debugger (and have committed a lot of random console logging) and there are often conflicts when more than one person is working on a file. To address that, there is a Slack channel dedicated entirely to announcing what file you are working on.
So I have a comment "Commit comment" in my html that I adjust a capitalization on then push again.
Works 100% of the time
I expect to end up in the 500k commits club
Edit: this is mixing up two things, what you want in this case is "git commit --amend -C HEAD && git push -f", i.e. replace the current commit with a new hash and force push.
Alternatively you can create an empty commit as above, but that isn't amending.
> No one liked how any of this worked, but just accepted it as a fact of life, like how you would accept that it really sucks that it rains today. That’s an attitude I’ve seen more often and never really understood: if I see something that’s really awkward, frustrating, and time-consuming then I want to fix it, but a lot of people seem happy to just and accept it.
And since this is a shared behavior, even your potential fix can be hard to get reviewed because everyone will be afraid of the potential side effects because nobody understands why it even worked like this.
Often, the root cause of this will bite you hardest when you need it least.
so much this
At some point I got addicted to the number, so from time to time I try to manually increase my frequency of commits.
All that said, I end up doing more commits when working on front end stuff, when I doing back end programming, I am not at all interested in saving / committing frequently as I’m focused on the task at hand. With front end stuff, you necessarily need to save and refresh the webpage in your development browser, so it goes hand in hand with increasing my commits :-)
For me, commits of work in progress are only done on my development branches before I want to push to a remote to save my work in case of my computer failing (or getting lost/stolen, whatever force majeure), I usually write a "WIP: <what's been worked on>" message that I will squash later on when I have a meaningful commit.
You can commit every single character if you in the mood. At the end, when your new feature is complete, you just squash all commits in this branch to one single commit ("add feature xyz") and merge/rebase it to your main dev branch.
Now it is really easy to identify the actual code behind a new feature.
The majority of this article could be seen as negative toward the author's former employer. The website is also listed on the author's CV, and knowing the author's name it is easy to find the website. Is there the possibility that this is seen as unprofessional, or that someone who was involved might read it and be upset? Maybe it is okay because the company is defunct (I assume), or because it was so long ago?
I ask because I am early in my career and I just finished a job where the majority of the things I learned were non-technical in nature. I would like to write about the lessons learned but, like this article, it would have some component of criticism about the company. Like the author, my website is on my resume and the website can be found by searching online for my name. Someone reading my resume could figure out what company I'm talking about, and some people who work there might find it. I don't live in a large tech hub in the US so it's very likely a future potential employer knows some people personally that I might have criticized vaguely (but due to process of elimination from the jobs listed on my resume wouldn't be hard to identify).
The advice I've been given from people I know is to either not have a website tied to your identity at all, or be as professional as possible if it is tied to your identity.
What do you think? If you knew this author, or it you stumbled across this article because you are thinking of hiring the author, how would you feel?
I at least know a few companies that would avoid hiring people who criticize old employers, afraid they will be next. I mean, most companies have at least some "skeletons in the closet" of bad practices or what not.
Having said that I'm usually brutally honest in job interviews, I see it as my way of screening companies, if they don't want the honest me, then I would probably not fit the company culture anyway. So there might be nothing wrong with having an honest blog in the end, maybe you receive less offers, but the offers match you more.
I've seen people advise that you should "avoid controversial topics" on first dates, as that "might be a turn-off". Well, maybe it can be (certainly had a few dates like that), but that would also be boring conversation, and not very meaningful as such if you're actually looking for a serious relationship (which doesn't apply to just romantic relationships by the way, also other kind of social relationships). Related comment from last year: https://news.ycombinator.com/item?id=23788380
It's partly cultural as well; I've seen this in certain countries (cough England cough), where everyone avoids talking about anything meaningful so all they talk about is the weather or some such pointless conversation because they're afraid someone could possible disagree with something they say. It's not like I'm against small-talk, but if that's all you do... Okay, I'm exaggerating a little bit, but it's certainly very different from my own Dutch culture where people tend to be a lot more forthright.
It's not like I will just say whatever without any filter or consideration for other people's feelings, or what might be inappropriate, or without being receptive to feedback. Actually, I try to be quite conscious in how I communicate, especially online where the lack of body language and diversity of culture/social norms can make things pretty darn hard. But at the end of the day this is mostly about how you say something rather than what you say. e.g. "this is stupid" vs. "I'm not sure if this is a good idea".
There are always trade-offs of course. I was known as "Carpetsmoker" online for years and I changed it across the board over a period of a few years to "arp242" mostly because I felt "Carpetsmoker" didn't sound too professional (a lot of people seem to associate it with drug use – I don't even like to smoke cannabis! It was just a funny joke I made when I was 14 that turned in to a nickname). I still think it's kinda funny, but what's an appropriate nickname when you were 14 isn't necessarily appropriate when you're 36 and actually use your GitHub as a way to earn your living, and it doesn't really matter all that much what your name is; so I just changed it.
I publish it on my personal name because I see it as my personal space. Being anonymous would make it "arp242's personal space" rather than "Martin's personal space". I know some people like to keep their "online identity" more separate from their "real life identity", but personally I don't really separate things out all that much.
This is a bit rambly maybe; I'm having a hard time to articulate my feelings on this ... but I hope it makes sense.
And, of course, everyone can make their own choices in this.
Or people just want to do the work in their mother tongue instead of a foreign language. Personally, it's quite disappointing to the see Englishification of The Netherlands. Even been to restaurants were I couldn't even speak in Dutch in Amsterdam and had to order in English. Bloody ridiculous. I don't think you will see that happen in London.
Depending on the kind of work I prefer to do things in Dutch, English or German. Anything mathematics is something I prefer to read about in Dutch, while some social science or anthropology related subjects I prefer to read in German.
> People often seem dismissive of that value i18n, “everyone speaks English” Well, depends on who your customer base is. Even in the Netherlands where almost everyone speaks some English there are still loads of people who are not especially good at it and much more comfortable with Dutch. This is probably over half the population, and it’s really not just old people.
Heck, I've worked at companies where over 50% of the employees did not speak Dutch at all.
So English will reach a wider audience in Amsterdam, ironically. Not sure how well this applies to the rest of the Netherlands (especially outside Randstad).
> Or people just want to do the work in their mother tongue instead of a foreign language
These two sentences mean the same thing. While sometimes people say “or X” to reword X I don’t see why you’d do that. It’s clear as it is.
For example, Netflix is doing a bad job at providing Dutch subtitles. Barely any tv show has Dutch subtitles. Disney+ does a much better job.
I've known a few people like this. One guy told me he realized programming wasn't for him after he'd been out in the real world for a year or so, but it just paid so much he didn't know what to do. I know another guy who just goes job to job and lasts about 6 months to a year before getting axed. He's able to do it because there's just so much demand in the market.
> Almost all of the company consisted of very junior people, often with no experience outside of that company.
Lesson to learn: there is a reason why experienced coders cost more.
However, it's also bizarre because it seems to not just contain an explanation of this weird tech but a lot of vitriol. This guy seems to have outlined what was a dysfunctional place where a lot of junior people got a nice start to their career. This doesn't seem to me to be a good reason to badmouth the place. You as a senior engineer should be helping people to be better coders, not shitting on them for being junior developers. (And yes the owner was bad but that's no reason to shit on the juniors!)
I think if I were interviewing this guy and saw this piece I would immediately slam then Strong No Hire button.