Let’s say it takes half a second to copy/paste and submit the message. That’s 50 seconds saved, round it to one minute. You’re only doing it once, so let’s cross over to yearly. According to the Munroe Automation Scale, you can spend up to 5 minutes on it.
I’d say that code took about 1 minute to write. Maybe 2.
Caveat: This is all written assuming the message is being written on a computer with a real keyboard. But if we’re assuming this is written on a phone, then my analysis doesn’t apply, but then again, writing a java program to execute in your messaging app is also a terrible idea. Which means we’re suspending disbelief, so I choose to believe that a computer keyboard and shortcuts are available.
Type the phrase once. Select all. copy, paste, paste (the first paste replaces what you already have highlighted, the second paste adds a second copy). Now you have 2. Control + A, Control + C, Control + V… Now you have 4.
It will take you only 7 cycles of this get 128*, you only need to copy/paste it one by one if you want to send each message separately. and even then, it’s would purely be copy the original, then paste, send, paste, send, paste send, paste, send.
Assuming you can hold down control and just hit ACVV 7 times, that’s 28 keystrokes. I’d bet I can get that done in 5 seconds or less (i tried it, it’s less than that), so now I only save 5 seconds. Which means I only get 25 seconds to write the script. Which he chose to write in java for some reason?
[print(“I’m sorry”) for x in range(0, 100)] is actually a script I could write in less than 25 seconds.
*And I disagree with the “reason 4” given. She didn’t say “exactly 100 times” she said “100 times before I forgive you” and to me, “before” implies >= and not ==. So if you drop it in 128 times, that exceeds the criteria. No one has ever rescinded forgiveness for receiving extra apologies.
How to go from only being able to compile the project on a Windows machine (due to obscure dependencies that every other Java project has for some reason) to not being able to compile on anyone’s machine in just 1 simple step.
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.
The problem with java is the language and how it works itself, and not the byte code idea.
I say that as a few things do that and .net, java and wasm are the first that jump to mind.
Hell, pure technically any programming language that is not asm does that :')
My problem is java itself, not its byte code. Wasm as advantage, imo, is that its not stuck to a single language like java is. .net blazor can build to wasm, but you could also use c++ to compile wasm applications :)
I’m not sure why the WASM creator(s) didn’t take advantage of the existing java bytecode and JVM instead of reimplementing it. Might’ve sped up its adoption. Doesn’t matter to me though, as long as JS stops being the #1 in web development.
Why would they? WASM is Web-Assembly, so Assembly is a lower level language than Java.
You can use C# WASM through Blazor, and Java WASM though JWebAssembly. WASM as core is supposed to be language agnostic. So If you want a JVM in WASM you can build it on top of it
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.
…and? You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up into a single “Add endpoint to allow users to set their blah blah” comment with a nice extended description.
You then rebase so you have a nice linear history with no weird merge commits hanging around.
Okay honest question, when you merge a PR in GitHub and choose the squash commits box is that “rebasing”? Or is that just squashing? Because it seems that achieves the same thing you’re talking about.
You should IMO always do this when putting your work on a shared branch
No. You should never squash as a rule unless your entire team can’t be bothered to use git correctly and in that case it’s a workaround for that problem, not a generally good policy.
Automatic squashes make it impossible to split commit into logical units of work. It reduces every feature branch into a single commit which is quite stupid.
If you ever needed to look at a list of feature branch changes with one feature branch per line for some reason, the correct tool to use is a first-parent log. In a proper git history, that will show you all the merge commits on the main branch; one per feature branch; as if you had squashed.
Rebase “merges” are similarly stupid: You lose the entire notion of what happened together as a unit of work; what was part of the same feature branch and what wasn’t. Merge commits denote the end of a feature branch and together with the merge base you can always determine what was committed as part of which feature branch.
Note that I didn’t say that you should never squash commits. You should do that but with the intention of producing a clearer history, not as a general rule eliminating any possibly useful history.
You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up
The next step on the Git-journey is to use interactive rebasing in order to never push these commits in the first place and maintain a clean history to be consumed by the code reviewer.
Squashing is still nice in order to have a one-to-one relationship between commits on the main branch to pull requests merged, imo.
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.
Python supports both, it’s just not pythonic. It’s not the way it’s meant to be written but you can write them if you want/are a masochist, because of the syntax’s flexibility.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.