Everywhere I’ve worked, you have a Windows/Mac for emails, and then either use WSL, develop on console in Mac since it’s Linux, or most commonly have a dedicated Linux box or workstation.
I’m starting to see people using VSCode more these days though.
I think someone else said what it actually is in another comment. It’s functionally identical 90℅ of the time for me anyway,and I use CLI and vim on it.
They’re both UNIX-like, i.e. they both implement the POSIX specification and are therefore in many ways compatible.
But yeah, modern macOS is more directly derived from the original UNIX operating system.
Linux was instead implemented from scratch to be compatible with UNIX.
The entire IT ecosystem is built around Linux, because it’s so prevalent in servers, containers, budget hardware and the open-source community.
Yes, many companies don’t understand that and expect their devs to be productive on Windows. But in my experience, that’s an uphill battle.
In my company, we get very little IT support, if we decide to order a Linux laptop and we still have significantly less trouble with getting things set up to start coding.
Not to mention the productivity boost from having all the relevant technologies natively available + being able to script whatever you want.
Hmm… theoretically this is more efficient, however in practice you may end up with a dirty cache… I guess that’s fine if you don’t mind corruption of your coworkers.
Rereading it, I now understand what you meant. I interpreted the “like regex” as an example of advanced git knowledge. I’m not sure the comma helps make it unambiguous though.
Yeah, reading it again and I can see that interpretation…
This is why you shouldn’t rely on yourself alone for proofreading your writing, I probably could have read that a hundred times and not seen another way to read it without someone else pointing it out
I have only ever used simply “git push”. I feel like this is a “how to say that you barely know how to use git without saying that you barely know how to use git” moment:-D.
The first time you manually push like that, you can add the -u flag (git push -u origin master) to push and set the branch’s default upstream. Afterwards, a plain git push while that branch is checked out will push the branch to that default upstream. This is per-branch, so you can have a main branch that pulls from one repository and a patch branch that pulls and pushes to a different repository.
My strategy is to just type git push and get some kind of error message about upstream not being set or something. That’s a signal for me to take a second to think about what I’m actually doing and type the correct command.
I can follow along re-typing the same commands told to me by a more senior dev just like any average monkey!
This reminds me of something I made a long time ago: img
Since I am calling myself dumb, I estimate my progress to be somewhere perhaps at the 20th percentile marker? :-D One of these days I’ll RTFM and rocket all the way up to be dumb enough to properly qualify for “below average”! :-P
It’s git push origin branch and then merge after submitting a pull request from branch to main after a successful lint check, build, deployment, and testing in a non-production environment, and PR approval. What kind of wild west operation allows pushing directly to main?
Our changes land in main at my workplace, once they’ve received a code review and all CI checks pass (which includes tests, E2E tests, etc). We use feature flags rather than feature branches, so all diffs / pull requests are against main. We use continuous deployment which means changes are automatically deployed once landed. Changes roll out just to employees, then to servers used by a small percentage of users (2% I think), then everywhere. All risky changes are gated by feature flags so they can be enabled or disabled without a code push.
We just had a customer escalation caused by exactly this. One group relied too heavily on tribal knowledge for code reviews and didn’t want any other process. Once the tribal elders were gone, no one knew all the things to look for, and there was no other way to catch issues
As a Continuous Integration and Test guy, I was standing in the corner yelling “I thought you were DevOps. Where’s the automation?” Fine, Puppet/YAML doesn’t work with a traditional build and test, but you could have done syntax validation and schema validation that would have caught before the code review could have happened (and I showed them how a year ago, even offered to do it for them) and set up some monitoring to discover when you break stuff, before customers discover it.
Do you not use a fork as your origin, separate from the production upstream repo? I’ll push to my fork’s main branch for small or urgent changes that will definitely be merged before anything else I’m working on.
If it’s a private repo I don’t worry too much about forking. Ideally branches should be getting cleaned up as they get merged anyway. I don’t see a great advantage in every developer having a fork rather than just having feature/bug branches that PR for merging to main, and honestly it makes it a bit painful to cherry-pick patches from other dev branches.
I never worked anywhere where they had this set up. I would push to branches and make pull requests, but always work in the production environment.
I was mainly working as a data engineer though so that’s probably why. It’s hard to have test environments since you can’t replicate all the enormous amounts of data between environments without huge costs.
There are many strategies for maintaining test environments for that kind of thing. Read-only replicas, sampling datasets for smaller replicas, etc. Plenty of organizations do it, so it’s not really an excuse, imo.
No I know. But it was “good enough” for the company and we never had any serious issues working that way either. If someone pushed a faulty commit, we just reverted it and reloaded the data from the source system.
A lot of companies have kind of bad solutions for this sort of stuff, but it’s not talked about and nobody is proud of it. But it keeps the environments simple to work with.
No kidding. Never push to main, and you most likely can’t. While I get the joke of the meme, I’d send the person packing if they don’t understand branching, and branch flow, rebasing or reverting. Even if you look up the command or do it all through your IDE, understanding the workflow of using git is important
Git itself does not use that standard yet, so at least now there are two competing standards.
I get that there are cultural reasons why the word master was loaded language, but still, it’s not like institutional racism will go away. Meanwhile, the rest of the world which doesn’t struggle with the remnants of slavery has to put up with US weirdness.
Git itself does not use that standard yet, so at least now there are two competing standards.
Just ran git init in a brand new empty directory, and while it did create a master branch by default, it also printed out a very descriptive message explaining how you can change that branch name, how you can configure git to use something else by default, and other standards that are commonly used.
Also, there’s nothing saying your local branch name has to match the upstream. That’s the beauty of git - you have the freedom to set it up pretty much however you want locally.
Yeah, that’s what I’m saying, there is no one standard now. The stupid thing is all the problems that causes is mostly because there used to be one, and stuff written assuming master branches are eternal.
I’ve had a company that had some automation built on git but below GitLab that would not let you delete master branches. When main became a thing, they just started hard protecting those as well by name. It’s because of regulatory, and they are very stingy about it.
So when I created a few dozen empty deployment repos with main as the default, and then had to change it over to master so that it lined up nicer with the rest of the stuff, I’ve had a few dozen orphaned undeletable empty main branches laying around. A bit frustrating.
That said, the whole thing is just that. A bit frustrating. If it makes some people feel better about themselves, so be it. I am blessed in life enough to take “a bit frustrating”.
Yeah that’s fair, I can see how that would be annoying for sure. I think that frustration stems more from company policy though, not necessarily the standard changing. And you know what they say, there’s nothing certain in this world except for death, taxes, and standards changing
It is trash code for sure, but most of the world’s code is trash, so we do have to accommodate trash code when we design stuff. That said, they do need to do this to comply with laws and make sure code doesn’t get lost (it’s finance), and this was the easy way to do it. Doing it better would have taken time and attention away from other stuff.
And standards do change, but they usually change to accommodate new features, or a new software product displaces an old one. I don’t really know any tech standard that changed because of cultural reasons. Point is, change is a cost. It may be worth to pay the cost, but here the benefits were US cultural sentiments that most of the world doesn’t care about.
And the stupid thing is that even when standards change, you are not usually labelled as culturally out of touch if you don’t follow it. Most big orgs don’t follow changes that they don’t need to. Nobody calls you a bigot for running COBOL mainframes in 2023, but they might if you predominantly have master branches.
I guess my perspective is that some people I know were mildly annoyed before lunch about it one day two years ago, since nobody cares about US identity politics, with my personal opinion being if the US didn’t fill up its for-profit prisons with black people who it then those prisons profit off of (just as an example), the word master would not bite as hard, and the whole thing would be moot.
If you don’t have autocomplete set up for your shell, get it working. If someone has a different branch named ma…, ask if you can delete it, and get your team to adopt a decent branch naming convention.
I really wish to work in a team where people have naming conventions for branches that are concerned about stuff like that. Must’ve been a nice place to work at.
I think the reasons was ridiculous. The fact that people didn’t like the word master anymore. But I’m used to it now, so fine, let’s use main. It makes sensitive people feel better.
I think HR is just ill equipped for technical interviews, but they try to conduct them regardless.
Was denied a position because HR felt my experience “lacked depth” which I still can’t understand 3 years later.
Did the same role at a larger company. Had more responsibility than they were giving me. Developed my own tools for job automation. Grew their business from nothing to half a mil a month. Experienced all stages of growth and realized massive success.
After that interview I kept getting technical interviews and getting passed on because I was too senior for the position
Funny enough, I probably did more software engineering as a web dev than I did as a software engineer at some companies.
In the UK, at least, the only difference typically between a web developer and a software engineer is £15-20k in salary. Frankly, we’re all software engineers…
About half of the equivalent in the US, often less. It’s exceedingly rare to make 100k here even in a senior position, although it does exist. Median is 40-50 (pounds, so times that by 1.2 for USD).
Afaik it’s similar here in Germany.
BUT you need go remember: We have social insurance and don’t need to pay 5000$ when taking the ambulance etc. etc.
So if you exclude that we may come close if you need to see a doc on the regular.
Even then it’s a pay cut. I know some people who moved to NA, and egotistically it’s a sound decision because engineers there are on the right side of the wealth disparity ravine. Money’s good enough that you don’t need social safety nets. And if push comes to shove, someone making $100k/y can definitely afford health insurance and the occasional trip for medical tourism.
Now personally I believe in income redistribution so I’m happy to pay a lot of taxes in one of the most income-egalitarian countries in the world. But I’d make a shit-ton more if I lived&worked in Luxembourg or Canada.
Then you need surgery and your COL is already >50% of your net income and you are a 100k in debt. And assuming you have savings, I’d rather spend them on myself (vacation etc.) rather than brace for my bankruptcy because I stood up wrong.
Now personally I believe in income redistribution so I’m happy to pay a lot of taxes in one of the most income-egalitarian countries in the world.
These careers do have decent insurance in the US. Long term illness is a different beast, but the most of ever pay for a medically necessary surgery is $3800, which is my max out of pocket. And I’d get short term disability which pays both 80% of my salary to me, and some amount to the company to compensate for my lost time.
Good jobs in the US really don’t have as many horror stories you are always hearing on the internet. I mean, we have lots of other horror stories which are totally true, like our schools being violent and deadly. And rural areas being filled with the stupidest people on the planet. And even in lots of tier one US cities, the public transportation being useless.
How do these comparisons look if we go by pay per hour worked? Because here in Germany the maximum amount you are allowed to work in a week is 60 hours. Unless in special positions (like the ones that have harvesting season or mine stuff), this has to be equalised down to 48 over a 6 week period at max (the special ones just have a longer period for it or a different timing system on what counts as break). If you are in a position that equals to 48 hours a week (6 day week), your minimum PTO is 24 days. If you have a 5 day week it is 20 days, and the numbers above shift down to 50 and 40 respectively. Most jobs that have any kind of skilled work behind them have 30 days PTO. Plus there are a lot of national holidays.
I work in taxes and the average days worked in a year is assumed at 230 (if we don’t have information otherwise ofc). That is less than 2/3 of the year.
Whereas my knowledge on the US is that 60 hour weeks are not necessarily an exception, you get way less PTO, you have less national holidays and you often need to network after hours to even be successful to a moderate degree (of course networking is a thing here as well, but it isn’t that necessary at a medium level, only if you want to get the high positions).
COL is not anywhere near $50k/y ($4100/mo!) except maaaybe in some very narrow parts (basically just SV an Manhattan, assuming you want a decently large apartment). But in either of those places an engineer makes up for it by making $150k/y instead.
Also rich Americans have good insurance, I’m sure you could find an example of someone who had this happen but it’s basically a non-risk.
And if healthcare was the only problem, then Canada would be an option as well. Engineers there still make a shitload more than German engineers. Watch out for the real estate market tho.
I did the math a few years ago when Trump was president.
I currently make double in America of what is made in other countries. It was something ridiculous like even if I had $35k a year in med expenses, I’d still be making more in the US.
Either American engineers are paid way out of proportion, or the rest of the world pays poorly. Either way, I’m going to ride this train before Skynet replaced me.
Yes, depending on where you live rent might be similar (London isn’t much cheaper than NY or LA) but cost of living is otherwise less. Also, people tend to work much shorter hours (a limit of 37 for me, any extra is returned as PTO) and start with much more annual leave (25 days discretionary, for me, plus public holidays, plus we close over Christmas and new year’s). Furthermore there’s no health costs to pay etc. On the whole it balances out and I think the lifestyle here is better, but I do envy the extreme salaries of those in the US.
As someone in the US, 40 hours per week is the minimum. Recognition for “being a hard worker” has required 60+ hours at some places I’ve worked. This is for a fixed salary and no overtime pay, mind you. Then you’re usually on an on call rotation every few weeks where you may have to work off-hours if something comes up. That’s additional unpaid hours. My current company pays $80,000 USD for new college grad software developers.
US holidays are 8-10 days, and junior devs usually start with 5-10 days of vacation. Health insurance costs at least several hundred a month (your employer also pays about 3x more than you towards your insurance premium as a benefit).
Despite incessant reassurance from recruiting that they have the best market data and we’re paying above average, I have reasons to suspect that’s not the truth. One of them being we’re hemorrhaging mid-grade talent and focusing on hiring backfills in Ireland and Hungary for much lower salaries. It almost seems like they’re trying to offshore the dev group via attrition to work around having to do layoffs…
Every HR department ever says that exact same thing. Even while the company is burning down and past bankruptcy.
Edit: For example, the fortune 50 I worked for insisted the same thing. Even when faced with industry data…they’d insist the Glassdoor and Indeed numbers were fake.
I left and got a 90% raise. That’s not a joke number.
It’s not too crazy here :) 25 days a year is the legal minimum and I get about 10 more than that, plus a few extra from doing overtime here and there. That’s why I say the lifestyle is on the whole better here even though we don’t earn nearly as much. It’s still plenty to pay the mortgage, and Europe is right on the doorstep to spend all that holiday time in.
You made that as a senior software dev in Finance more than a decade ago, more now (mainly because the pound went down versus other main currencies), especially if you’re working in the Front Office (i.e. directly with business, such as Traders and Analysts)
However breaking into Front Office IT in Finance without previous experience in your CV working in banking or similar is pretty though.
Sure, yes, but those kinds of positions in the US make 300k or more too. Also, then you work in finance and you have to live with the fact that you are categorically making the world a worse place every day.
I’d say you’re very underpaid, I’m making about 50% more than that in a fully remote UK-based mid-level position. You should start looking for a new job, even if it’s just as leverage to get paid fairly at your current place.
Oh yeah, I’m severely underpaid in my current job, even for where I live and what my role is. But I’m happy with my bosses and my colleagues. They’ve got my back more than not and I can be happy knowing I’m not in a hostile work environment. They are my genuine friends. Also helps that I enjoy the work I do. It’s not going to be my forever job but I’m savoring it while i can before I move on.
I already get paid more than the three directors, we’re a small company with very little money at the moment, and under threat of going under. They want to pay me more. It’s just if they did, the company goes under next month instead of a few months down the line if no new clients come to the table and actually commit to working with us.
Vacations maybe because that also depends on where you want to go. Cars can differ wildly, unless you want a sportscar or some such. Same goes for phones, often you get one „free“ with your contract for mobile. Gas/Petrol vary a lot, because of taxes and other state side things attached to them. Same goes for electricity plus those also depend on availability.
The thing is that for a majority of cases, this is all one needs to know about git for their job. Knowing git add, git -m commit “Change text”, git push, git branch, git checkout , is most of what a lone programmer does on their code.
Where it gets complicated real fast is collaboration on the same branch. Merge conflicts, outdated pulls, “clever shortcuts,” hacks done by programmers who “kindof” know git at an advanced level, those who don’t understand “least surprise,” and those who cut and paste fixes from Stackexchange or ChatGPT. Plus who has admin access to “undo your changes” so all that work you did and pushed is erased and there’s no record of it anymore. And egos of programmers who refuse any changes you make for weird esoteric reasons. I had a programmer lead who rejected any and all code with comments “because I like clean code. If it’s not in the git log, it’s not a comment.” And his git comments were frustratingly vague and brief. “Fixed issue with ssl python libs,” or “Minor bugfixes.”
I had a programmer lead who rejected any and all code with comments “because I like clean code. If it’s not in the git log, it’s not a comment.”
Pretty sure I would quit on the spot. Clearly doesn’t understand “clean” code, nor how people are going to interface with code, or git for that matter. Even if you write a book for each commit, that would be so hard to track down relevant info.
Yeah, I think that guy only got a superficial understanding of what Uncle Bob was saying.
My policy as a tech lead is this: In an ideal world, you don’t need the comment because the names and the flow are good. But when you do need the comments, you usually really need those comments. Anything that’s surprising, unusual, or possibly difficult to understand gets comments. Because sometimes the world is not ideal, and we don’t have the time or energy to fully express our ideas clearly in code.
My policy on SCM logs is that they should be geared more towards why this commit is going in, not what is being done. And what other tickets, stories, bugs it relates to.
Lead of a small team of scripters here. The “Why. Not What” is defo a good way of encouraging cleaner code.
Had to request changes recently on a PR like this, big function with comments telling me what it was doing. When they resubmitted for review they had broken it down into smaller functions with good variable/function naming. following what was going on was much easier
Same strategy here, but recently found myself commenting on the “what”. There was a perfect built-in, but not really readable and I couldn’t figure out how to make it readable, so fine
We solve that problem using naming conventions. Branch names must start with the issue key (we use Jira). You don’t do anything in that branch that’s not part of that issue. If you do, you must prefix the commit message with the issue key that it goes with. The commit itself identifies what changed. The Jira issue provides all the backstory and links to any supporting materials (design docs, support tickets, etc). I have to do a lot of git archeology in my role, and this scheme regularly allows me to figure out why a code change was made years ago without ever talking to anyone.
But when you do need the comments, you usually really need those comments.
It’s nice to see you sharing my experience. My code is either uncommented or very severely commented with comment-to-code ratios of 10:1 or more. I hate the files that are soo green… :(
It’s not git that’s complicated. The work is complicated. git is just one of the tools that programmers use to manage the complexity.
I also think that some people get too hung up on having a “clean” history, and trying to “fix” the history after it has already occurred. I usually have enough problems to worry about in the present, without also trying to worry about the past.
I like to rebase on my feature branches before the PR because it’s a gift to my future self that resolves all the conflicts (if any) before my work goes in. I just find trying to figure out how those conflicts got resolved when there are a bunch of merges in more difficult if there’s a problem later. It’s easier to understand for me. YMMV, this does not work for everyone. Etc etc.
Sure, if you’re they type to micro commit, you can squash your branch and clean it up before merging. We don’t need a dozen “fixed tests” commits for context.
But in practice, I have seen multiple teams with the policy of squash merging every branch with 0 exceptions. Even going so far as squash merging development branches to master, which then lumps 20 different changes into a single commit. Sure, you can always be a git archeologist, check out specific revisions, see the original commits, and dig down the history over and over, to get the original context of the specific change you’re looking into. But that’s way fucking more overhead than just looking at an unmanipulated history and seeing the parallel work going on, and get a clue on context at a glance at the network graph.
Using curated commits to optimize for pull request reviewability is highly underrated. Liberal use of interactive rebasing to ‘tell a story’, essentially.
In other news, never work more than one person on a branch (that’s why we have them). Make a new related issue with its own branch and rebase whenever necessary, and don’t even think about touching main or dev with anything but a properly reviewed and approved PR (in case they aren’t already protected), or I’ll find and report you to the same authority that handles all the failed sudo requests!
Also, companies that disable rebasing are my bane. While you can absolutely do without, i much prefer to have less conflicts, cleaner branches and commits, easier method to pull in new changes from dev, overall better times for the reviewer, and the list goes on. Though, the intern rewriting multiple branches’ history which they have no business pushing to is also rather annoying.
This is so incredibly dumb, though I’m sure I don’t have to tell you this. That comment will be buried in the git log if anyone ever fixes a typo on that line.
Those look pretty tame compared to some aircraft that actually took flight IRL - like Nemeth Parasol, Vought V-173, VVA-14, Coleopters, Flettner airplanes, and many, many more. Actually, they’d fit well as a following with “the projects they hire you to work on”.
Personal repositories aren’t production code. They’re learning opportunities. You tried adding 100 engines to a plane and learned that that was a bad idea. Who cares if there’s no cockpit if you were test-driving the wings?
This is just off the top of my head from a bit of experience in KSP, but depending on the thrust-to-weight ratio of the engines, it would probably be able to take off, but you’re right, it wouldn’t win any fuel economy awards.
Actually I doubt any material could stand that kind of wing loading, and the aerodynamics would probably be all kinds of fucked. Pretty apt analogy for a beginner developer.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.