I think it’s equal zero in this case. I’d have to look up the IEEE specification to make sure. AFAIK it’s just not guaranteed for any numbers and depends on the floating point implementation. A general rule of thumb for programmers is not to use ‘equal’ with floating point numbers.
Some people, like me, are not built to be developers. I can sculpt code in any language I need for whatever problem I need to solve, but maintaining code over a long period of time, with others, is not my thing.
The drive to do additional changes is just too high and the tendency for typos or obvious logic errors is too common. (There is one little improvement. It’s right there. One line up. Just change it now while you are in there…)
I am not stupid and regard myself as a decent engineer but my brain is just wired in a more chaotic way. For some things that is ok. For developing code on a team, not so much.
Security is the field I am most comfortable with because it allows for creative chaos. Rule breaking is encouraged. “Scripting” is much more applicable and temporary.
When using git and are working on a feature, and suddenly want to work on something else, you can use git stash so git remembers your changes and is able to restore them when you are done. There is also git add -p this allows you to stage only certain lines of a file, this allows you to keep commits to a single feature if you already did another change that you didn’t commit (this is kind of error prone, since you have to make sure that the commit includes exactly the things that you want it to include, so this solution should be avoided). But the easiest way is when you get the feeling that you have completed a certain task towards your goal and that you can move on to another task, to commit. But if you fail you can also change the history in git, so if you haven’t pushed yet, you can move the commits around or, if you really need to, edit past commits and break them into multiple.
I tell my young developers - the primary goal in software engineering is maintainability. Code reuse, encapsulation, abstraction, and myriad other concepts all contribute to ease of maintaining source code over the long term. Maintainability allows for easier, predictable feature addition and removal, with newer changes, and by different people. You’re also a different person than the one you were months or years ago when it comes to software.
Did I already post in here about how he wrote a custom DSL instead of using the standard widely used ORM we use everywhere? Maintainability nightmare.
He doesn’t work here anymore and now I have to either figure it out or rip it out. So far it looks like “rip it out” because it took less than an hour to swap in the orm, and now there’s just a lot less code needed.
No worries! I am generally very open about it. (Your comment was recognizable to me, actually. There is a geryy specific non-malicious bluntness that comes with the condition, actually.
But yeah, you have been practicing dealing with it your entire life. Treatment just helps a ton.
I’m the same way. Chasing code changes through the codebase then fighting with an edit rebase stack trying to explode them into less-interlocked changes.
It doesn’t always work, sometimes I am just committing a giant blob of changes at work on my project I near-solo maintain 💀
Very relatable. Especially when it’s less effort to make the change than it is to try and ignore it. But it’s understandably harder for those who are reviewing your work.
But part of working as a professional on a team is communicating and achieving consensus. Just trying to make a change like that out of the blue is poor form.
Also consider the opportunity cost: we had planned on getting XYZ done this week, and instead he spent a few hours on this and dragged a few people into a “do we want to change to poetry right now?” conversation
That wasn’t me, but that also used to be me. I learned to pick my battles, especially with complex code bases, and tried to keep scope creep in the name of improvement to like a dozen lines (provided it was fully tested).
I think it’s definitely a thing most people grow out of when they gain experience.
My boss told me about how when he was new he rewrote a whole chunk of the front end. His boss gave him a talking to about how you can’t just go and do that when you’re working with a team.
At an old job I just opened a PR to apply a code formatter to an internal project I wasn’t even a routine contributor to. PR was rejected and I learned a valuable lesson about talking and getting buy-in before making sweeping changes.
Yeah I’m just a gamer and learned about pc just to make my games work but that’s how I became so good at googling. Never learned how java works but I sure can find which arguments to set on my launcher to make my modded Minecraft run better.
Context is always useful, though. Because sometimes the person asking has gone down the wrong path and you could help them see the problem from a completely different angle.
Or maybe that context will let you know that yes, they have to use that ancient tech because that’s what they have to use at work and no they can’t install the latest fancy tech that does it so easily…
“Here is the answer, but why do you want that?” is a tolerable invocation of the X-Y problem.
“But why do you want that?” is derailing. It’s an effortless, all-purpose, I’m-so-clever bot post, and it drags a straightforward technical hurdle into some MacGuyver-ass lateral thinking puzzle.
I was once trying to incorporate 2D characters into Blender, with normals. There was no higher goal. That was, itself, the point. But instead I got a bunch of useless advice about how to model my simple example object, and snippy bullshit about doing things properly in 3D. Nobody had a damn thing to say about the discrepancy between the scanline renderer and the path-tracing renderer.
Last time somebody did this to me there were a lot of sit downs about how to properly chop up large scale code changes and why we don’t sit on our own branch for two months.
“How long will this take to get in?”
“Well, two weeks for me to initially review it, a week for you to address all the changes, then another week or so for me to re-review it… Then of course we have to merge in all the changes that have been happening in primary…”
Last time I got this PR I was like, “Okay, I’ll do my best, but you asked the guy that has like 30 mins a day to actually focus and look at someone else’s code AND yours isn’t the only PR I’ll have to look at this sprint. Have fun reminding me about this for the next week.”
As someone who works in IT, and specifically networking and security, the “trade subs” are honestly what I miss.most from reddit. Places like sysadmin, Cisco, Fortinet, talesfromtechsupport, etc.
It is honestly impossible to imagine copy-pasting code and getting it to work without knowing what you’re doing.
I had an acquaintance at uni who got a job at a software company by taking credit for a friend’s work and basically being the hack & fraud that the person in this post thinks they are - although I didn’t realise this at the time. He asked me to help him write some code that was needed for a presentation the next day. I decided to try to help, and I took a look.
It was a bug that required a little epsilon value to be tolerant of small changes in input in order to not constantly fire. I wrote that tiny bit of code and gave it back to him. Then he told me it wasn’t working and could I look at it again. I did, and there were two epsilon values with different names in it. I asked him about that and he said he had gotten help from another friend.
He had literally attempted to merge our two functions that did the same thing into one grotesque chimeric piece of code that would only have worked if he had accidentally made one or the other of our snippets inoperative. This was like a 20 line function. It was basic, easy shit. The guy didn’t know anything.
I didn’t explain this. I told him I couldn’t keep troubleshooting this for him and left him to it. To my understanding he was fired and cost that company a lot of money. But really if they couldn’t figure out that the programmer they hired couldn’t actually program then it’s really hard to feel that sorry for them. It seemed like everyone was flying by the seat of their pants.
I think you could definitely read and bugfix code without ever learning to “write” code. Code intentionally reads kind of like a language, it’s possible that this guy was just doing very simple tasks and the most he would have to change are variable names and values. Maybe he knows how to fix errors reported by the code and knows how to look for variables.
It’s a fine line between that and knowing how to code, but that’s kinda the joke of this post I guess.
I believe so. I have some roles in my team I’m hiring for, that have reading code and fixing small bugs as one of the requirements, but not developing code from scratch. (It’s a sort-of field engineering role).
We do test for both things (treating the “developing code from scratch” as bonus points rather than a strict pass/fail) and some people can find and fix bugs in a couple minutes, but are incapable of writing some basic python to iterate through prime numbers and store them in an array.
Yeah I think that’s what he meant. You don’t want CI editing commits.
I use pre-commit for this. It’s pretty decent. The major flaws I’ve found with it:
Each linter has to be in its own repo (for most linter types). So it’s not really usable for project-specific lints.
Doesn’t really work with e.g. pyright or pylint unless you use no third party dependencies because you need a venv set up with your dependencies installed and pre-commit (fairly reasonably) doesn’t take care of that.
Overall it’s good, with some flaws, but there’s nothing better available so you should definitely use it.
I’ve used pre-commit pretty extensively over the years and I’m confused.
Each linter has to be in its own repo (for most linter types). So it’s not really usable for project-specific lints.
Not sure what you mean by this. I have pre-commit set up to do linting in several different projects, and even have it running multiple differently-configured lint jobs in the same repo.
Doesn’t really work with e.g. pyright or pylint unless you use no third party dependencies because you need a venv set up with your dependencies installed and pre-commit (fairly reasonably) doesn’t take care of that.
Again, I have pre-commit set up on multiple repos running pylint with multiple different plugins. Pre-commit absolutely does take care of setting up venvs with needed dependencies.
Not sure what you mean by this. I have pre-commit set up to do linting in several different projects, and even have it running multiple differently-configured lint jobs in the same repo.
I don’t mean using lints, I mean writing custom ones. Say you have a custom lint you want to use but it only will ever be used for that specific project. You can’t just put the lint code in a subdirectory. It has to go in a separate repo.
Pre-commit absolutely does take care of setting up venvs with needed dependencies.
Again I think you might be misunderstanding. It will install pylint fine, but if your project does e.g. import yaml, it’s not going to set up a venv and install pyyaml for you.
Say you have a custom lint you want to use but it only will ever be used for that specific project. You can’t just put the lint code in a subdirectory. It has to go in a separate repo.
You can run locally defined hooks with pre-commit, just define them in the repo: local section of the .pre-commit-config.yaml, and have it run a bash/python/whatever script or something that invokes your custom linting, wherever it lives in your file structure.
It will install pylint fine, but if your project does e.g. import yaml, it’s not going to set up a venv and install pyyaml for you.
Yeah I misspoke there. For Python based stuff, it uses the currently active virtualenv or your global python install, so it relies on you installing your own dependencies. Which isn’t really that big a deal imo, because you need to install those dependencies to run/debug/test locally anyways.
You can run locally defined hooks with pre-commit, just define them in the repo: local section of the .pre-commit-config.yaml
Sounds like you’re just googling it rather than actually speaking from experience. Suppose I have written a Python lint and it’s in my ci/lints/foo folder. How do I tell pre-commit that? (Hint: you can’t)
Which isn’t really that big a deal imo
For small Python projects, maybe not. The project I’m working on has multiple sub-projects and those each have their own venvs, pyproject.tomls, etc.
Sounds like you’re just googling it rather than actually speaking from experience.
Like I said, I’ve used pre-commit for multiple years now. If you can run your lints from a command line, you can configure pre-commit to run them.
The project I’m working on has multiple sub-projects and those each have their own venvs, pyproject.tomls, etc.
Monorepos definitely make things a bit trickier, but again, you absolutely can write a local pre-commit hook that runs a bash command or script that 1.) activates the necessary venv and 2.) runs the lint command. I know this because I’ve done it, multiple times.
If you can run your lints from a command line, you can configure pre-commit to run them.
Yes but the whole point of pre-commit is it takes care of installing the lints. For most supported languages this requires the lint to be in its own repo. That is very annoying for project-specific lints that you would ideally want to just put in a subdirectory. Does that make sense?
can write a local pre-commit hook that runs a bash command or script that 1.) activates the necessary venv and 2.) runs the lint command. I know this because I’ve done it, multiple times.
Yeah there’s not really any point using pre-commit at that point.
Pre-commit hooks is a common approach to this, so that whatever is committed gets processed. Another possibility would be to set a bot on the repo to do automated commits after human-made ones, but that can get a little noisy.
I do like the idea of mandating git clang-format as the Kate project has.
That way the other devs don’t need to change their own IDE settings to comply.
I’m still annoyed that Github doesn’t have good support for stacked diffs. It’s still not possible to say that one PR depends on a different one, and still has no ability to review and land them as a stack.
Please, no, I get flashbacks from my 6-month journey (still ongoing…) of the code review process I caused/did. Keeping PR scope contained and small is hard.
From this experience, I wish GitLab had a “Draft of Draft” to tell the reviewer what the quality of the pushed code is at: “NAK”, “It maybe compiles”, “The logic is broken” and “Missing 50% of the code”, “This should be split into N PRs”. This would allow openly co-develop, discuss, and steer the design, before moving to nitpicking on the naming, formatting, and/or documentation details of the code, which is likely to drastically change. Drafts do work for this, but the discussions can get uncomfortably long and convolute the actual finishing of the review process.
Once both reviewer(s) and the author agree on the code design, the “DraftDraft” could be collapsed into a link in an normal Draft to be mocked next. The scope of such draft would be limited by the earlier “DraftDraft”.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.