The UK press every year makes a huge song and dance in opinion pieces about getting rid of DST. However I’m always horrified to see that people want us to keep British Summer Time instead of Grenwich Mean Time. I understand that there are “longer evenings” in BST; however we literally invented GMT and coerced the rest of the world to adjust their times based on that. From the point of view of being constantly compatible with UTC and having more consistent business hours for international companies it makes more sense to me if we kept GMT.
Also the longer evenings thing can be achieved by simply staying up an hour later. It’s not exactly like an hour is being stolen from you when the times switch, the change of clocks are mainly pointless admin.
Lastly I read an article recently that described a correlation between the incidence of heart attacks and the clocks changing. The theory is that just slightly messing with people’s sleeping patterns can cause additional strain on the body.
No the longer evenings are achieved by work starting and ending an hour earlier. And it’s literally easier to change the time zone than to change corporate culture.
I think I want work to end an hour earlier in the winter because of how early the sun sets, and care much less about the summer. So however it’s done, it would be great if office jobs could happen when it’s dark outside and we could live our lives during daylight.
Mmm yeah I’ve noticed that my retired parents keep telling me what a great summer we’re having every year and I’m completely unaware of it due to being cooped up inside.
Another point for GMT, in the mid '70s, the US went onto DST year round for a couple years. People hated it so much they changed back to switching the time.
If we wanna do away with DST and BST, we need to go back to standard time, as the later sunset in the summer translates to no sunlight for workers in the winter
I have been using something very similar to this. In my team I insisted on people without any git experience working on a separate local branch, than the feature branch
. To ensure screw ups are minimal, we pull and create a local feature branch and then a new local only dummy branch, on top of it. Once the team is more comfortable with git, I am planning to treat the local feature branch as a dummy branch.
So far things have been pretty neat. Spaghetti is no more with minimal conflicts.
No doubt. git rebase is like a very sharp knife. In the right hands, it can accomplish great things, but in the wrong hands, it can also spell disaster.
As someone who HAS used it a fair amount, I generally don’t even recommend it to people unless they’re already VERY comfortable with the rest of git and ideally have some sense of how it works internally.
Yeah it is something people should take time to learn. I do think its “dangers” are pretty overstated, though, especially if you always do git rebase --interactive, since if anything goes wrong, you can easily get out with git rebase --abort.
In general there’s a pretty weird fear that you can fuck up git to the point at which you can’t recover. Basically the only time that’s really actually true is if you somehow lose uncommitted work in your working tree. But if you’ve actually committed everything (and you should always commit everything before trying any destructive operations), you can pretty much always get back to where you were. Commits are never actually lost.
You can get in some pretty serious messes, though. Any workflow that involves force-pushing or rebasing has the potential for data loss… Either in a literally destructive way, or in a “Seriously my keys must be somewhere but I have no idea where” kind of way.
When most people talk about rebase (for example) being reversible, what they’re usually saying is “you can always reverse the operation in the reflog.” Well yes, but the reflog is local, so if Alice messes something up with her rebase-force-push and realizes she destroyed some of Bob’s changes, Alice can’t recover Bob’s changes from her machine-- She needs to collaborate with Bob to recover them.
Pretty much everything that can act as a git remote (GitHub, gitlab, etc.) records the activity on a branch and makes it easy to see what the commit sha was before a force push.
But it’s a pretty moot point since no one that argues in favor of rebasing is suggesting you use it on shared branches. That’s not what it’s for. It’s for your own feature branches as you work, in which case there is indeed very little risk of any kind of loss.
Ah, you’ve never worked somewhere where people regularly rebase and force-push to master. Lucky :)
I have no issue with rebasing on a local branch that no other repository knows about yet. I think that’s great. As soon as the code leaves local though, things proceed at least to “exercise caution.” If the branch is actively shared (like master, or a release branch if that’s a thing, or a branch where people are collaborating), IMO rebasing is more of a footgun than it’s worth.
You can mitigate that with good processes and well-informed engineers, but that’s kinda true of all sorts of dubious ideas.
Pushing to master in general is disabled by policy on the forge itself at every place I’ve worked. That’s pretty standard practice. There’s no good reason to leave the ability to push to master on.
There’s no reason to avoid force pushing a rebased version of your local feature branch to the remote version of your feature branch, since no one else should be touching that branch. I literally do this at least once a day, sometimes more. It’s a good practice that empowers you to craft a high-quality set of commits before merging into master. Doing this avoids the countless garbage fix typo commits (and spurious merge commits) that you’d have otherwise, making both reviews easier and giving you a higher-quality, more useful history after merge.
Why should no one be touching it? You’re basically forcing manually communicated sync/check points on a system that was designed to ameliorate those bottlenecks
No, you divide work so that the majority of it can be done in isolation and in parallel. Testing components together, if necessary, is done on integration branches as needed (which you don’t rebase, of course). Branches and MRs should be small and short-lived with merges into master happening frequently. Collaboration largely occurs through developers frequently branching off a shared main branch that gets continuously updated.
Trunk-based development is the industry-standard practice at this point, and for good reason. It’s friendlier for CI/CD and devops, allows changes to be tested in isolation before merging, and so on.
That one dude still using Delphi is getting screwed.
Also, these salary numbers seem… real low. I get that it’s the median so maybe a huge number of overseas engineers are pulling the results down but in my neck of the woods 105K is less than what we pay juniors.
Lots of little quality of life things. For instance, in Kotlin types can be marked nullable or not. When you are passing a potential null into a non-nullable argument, the compiler raises an error.
But if you had already checked earlier in scope whether or not the value was null, the compiler remembers that the value is guaranteed not to be null and won’t blow up.
Same for other typechecks. Once you have asserted that a value is a given type, you don’t need to cast it everywhere else. The compiler will remember.
Cargo is really simple, which is great, but also limiting. Maven is much more complex, but for good reason - there’s use cases, especially around multi-artifact projects and version sharing, where cargo would require either some glue or you run into some interesting edge cases. Usually, Rust isn’t used for the kinds of big, wacky projects with a million dependencies that companies write in Java/Kotlin, so those kinds of use cases are considered more unusual.
Gradle, in my opinion, makes itself complex because it’s all code, is very brittle, and several of its features just don’t work right and require workarounds. When it works, it builds fast and it works well, but getting it to work, and how often you have to get it to work again…not worth it.
The XKCD Standards comic writ large. There are 17 competing standards. -> “Hey, we should make a standard to unite all these disparate standards.” -> There are now 18 competing standards.
This is literally how this all started for us lol. Senior wanted to try to migrate everything to Kotlin in our project. Migration never finished. Now one of our major repos is just half Kotlin half Java. Devs on our team learn Kotlin by unexpectedly encountering it when they need to touch that code.
Maybe it’s because I know both languages but is that really a big issue for people? The interop is great, and kotlin is very readable, so the cost of context switching between the two is miniscule.
Some people have an extreme aversion to learning new things though. I feel that holding yourself to the standards and limits of your lowest performers isn’t a great thing.
Sounds like you’re making progress, your devs are slowly learning a better language that will let them work faster and will soon be able to help port the rest of the codebase and then you can really accelerate when no one needs to touch or know Java.
I really hope so. Last code I reviewed was full of !! and companion objects trying to emulate Java static instead of top-level consts. Even I’m still trying to figure out what idiomatic Kotlin looks like. We got a ways to go…
Doesn’t Kotlin has interoperability with Java? I didn’t used it much yet but I’m about to in a few months. Is it that difficult to just refactor things to Kotlin when you need to change something in the project? I’m asking because I just can’t work with verbose languages and would prefer Kotlin to Java everyday.
The interoperability is both a blessing and a curse imo since it let us half-ass the integration by leaving a bunch of Java code unconverted. I could start refactoring everything but then my team would stop reviewing my PRs due to the diff size (and then my manager would eventually find out that I’ve been using up work time doing this instead of shipping features during crunch week).
I really much prefer Kotlin to Java. I just wish my team had actually had a commitment to it instead of just sorta using it with no migration plan.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.