Should be at least double in the US since it would be consultancy work which brings higher taxes (1099 vs W2) and no benefits. A $500 full day consultation is super cheap.
If he was serious, your dad seems like a prick that sees you as an appendage that he owns…
This seems as good an opportunity as any to tell him to go fuck himself and learn some boundaries - not sure if you need to hear this, but blood doesn’t get a pass just for being blood. Make ALL the people in your life earn their place there by treating you decently.
Woah buddy, you’re at about a 9, we need you down at a 3.
“Dad” doesn’t know anything about web design, but he knows (presumably son) makes them, and he ballparked a number making the entirely common armature mistake of thinking it’s as easy as setting up your facebook page. He’s also not demanding anything here. Nothing about this exchange suggests that “Dad” was going to require that the work be done at the stated price. It seemed like
Maybe before you go burning bridges and obliterating a family relation, consider how much easier it is to tell “Dad’s Buddy” that while Dad was well meaning, he was way off, and Buddy is free to compare with other estimates, but $X is actually a much more reasonable value.
also, feels pretty obvious you haven’t been involved in bidding jobs before - these initial numbers set expectations. If “dad” valued the kid’s talent and time, he would have said, “they’ll give you a number” and/or the message to kid would not have been closed, it would have been open. So instead of, “you’ll do this, thanks bye” it would be a question to kid prior saying, “I know a lot goes into your work, is $500 a good ballpark to give my friend for something like this?”
It’s about expectations and entitlement - you’re essentially my property, so I decided it would be this is indicative of a problem with “dad’s” approach.
I try to keep my changes under 300-350 lines. Seems like a good threshold.
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.
also iirc gitlab does offer something like this as a feature now with “merge trains” (though i’ve never really used it, usualy just go for the feature branch out of habit x) )
Making PRs against a feature branch still has the same problem.
Say you’re working on a major new feature, like adding a new log in flow. It’s a good idea to split it into many small changes: create initial log in form, implement user sessions, add SSO support, add “remember me” functionality, etc.
Those changes will likely depend on each other, for example adding the “remember me” checkbox requires the form to actually be built, and you probably don’t want to wait for the reviewers to review one change before continuing your work. This means you naturally end up with PRs that depend on each other in a chain.
Stacked PRs (or stacked diffs, stacked MRs, whatever your company calls it) means that:
The code review tool lets you specify dependencies between the PRs, for example the “remember me” PR depends on the initial login form implementation
It shows the dependencies visually in the UI, like a chain or tree
Changes can’t be landed until the PRs they depend on have been reviewed
There’s a way to land an entire stack
When you review a PR later in the stack, it doesn’t show any of the changes that were made earlier in the stack. Each PR focuses just on the changes in that part.
Making all your commits directly to a branch then creating a PR for the whole branch is similar, but reviews are a nightmare since it’s only a single review for the entire branch, which can be thousands of lines of code.
At my workplace, we use feature flags (essentially if statements that can be toggled on or off) rather than feature branches. Everyone works directly from the main branch. We use continuous deployment which means landed code is quickly pushed to production. New features are hidden behind a feature flag until they’re ready to roll out.
You can make a PR against your feature branch and have that reviewed. Then the final PR against your man branch is indeed huge, but all the changes have already been reviewed, so it’s just LGTM and merge that bad boy!
I suppose it is possible to have two PR that have changes that depend on each other. In general this just requires refactoring… typically making a third PR removing the circular dependency.
It sounds like your policy is to keep PR around a long time, maybe? Generally we try to have ours merged within a few days, before bitrot sets in.
Sorry, my comment was unclear. I didn’t mean a circular dependency, just PRs that have a chain of dependencies (e.g. PR 100 that depends on 99, that depends on 98, that depends on 97)
They’re usually not around for a long time, but there can be relatively large chains if someone is quickly adding new features.
I think it depends. I’ve had a non-technical PM and he was great. He knew he knew nothing about development and as such did what great managers do, create an environment where we could work as efficiently as we could. If we said it takes X amount of time he wouldn’t try to squeeze out a faster deadline, he’d report “it will take X amount of time”. If we said it’s unreasonably to take feature Y in he’d say we’re not going to take feature Y in.
IMO it’s much harder with PMs who did some development 20 years ago and “know how things are done”. The ones with some technical knowledge almost always butt in.
I’m gonna make you break this up into multiple PRs before reviewing, but honestly, if your refactoring reduced the surface area by 20% I’m a happy man.
Could be a “You can’t let John down now, we’re old pals, and a few people expect the site to work by the end of the week. He just needs a site like Facebook, but for gardeners”
Even just an afternoon of CSS would mean 2-4 hours, plus setting everything up, plus talking to the client, revisions, etc. You’ll quickly end up with 10h overall, even if the actual task is rather small. And that’s the optimistic case.
So you’ll end up with maybe 50€/h , probably more like 30. Not terrible, but that’s the optimistic case.
Backend Requirements: “When x,y goes in, I want x+y to come out!” - Okay
Frontend Requirements: “Well it needs to be more user-friendly, and have this rockstar wow effect” - Yea wtf are you even talking about? You want me to add random glitter explosions, because I found a script for that, that’s pretty ‘wow effect’ right?
Isn’t our main audience German? If you wanted non German stuff you shoulda asked for regional translations. Not only is that a change request, but you’re gonna be pushing the release window by months.
I spent years as a mobile developer and the thing that always drove me the most nuts was being handed a software design with lots of tiny buttons that were nearly impossible to tap with a finger. I generally implemented the UI by increasing the size of the tappable regions (without increasing the apparent size of the buttons) making it actually usable, but one time the designer discovered that I was doing this and went apeshit and convinced the project manager to order me to undo all this and make the tappable regions the same size as the buttons. The grounds for this was that implementing the larger tappable regions would take too much extra time - despite the fact that this had already been done and it took additional time to undo it.
I usually just do what they requested and when they come to complain I just tell them “well, you’re the one who requested this” and pull up receipts. My DM to myself on Slack is filled with screenshots and links to confirmations for bullshit requests that the product team made.
Real back-end requirements: when x, y goes in (in JSON-as-an-XML-CDATA-block because historical reasons), I want you to output x+y+z+æ+the proof to P=NP.
æ will require you yo compile x+y in CSV, email it to Jenny, who will email back the answer. She doesn’t quite know how to export excel sheets though so you’d better build a robust validator. No, we don’t know what æ is supposed to look like, Rob from Frontend knows but he’s on vacation for the next 8 months.
The request must be processed under 100 ms as the frontend team won’t be able to prioritize asynchronous loading for another 10 sprints and we don’t want the webpage to freeze.
And why does your API return a 400 when I send a picture of my feet? Please fix urgently, these errors are polluting my monitoring dashboard and we have KPIs on monitoring alerts.
Yea, fair enough. My point was mostly: backend requirements are usually at least objective. “Json xml comes in”, “CSV goes out by email”, “The request must be processed under 100 ms”, “API should not return 400 on feetpics” - these are still mostly objective requirements.
Frontend requirements can be very subjective “The user should have a great user experience with the frontend”
Hahaha that’s what frontend devs think, but the backend requirements are just as vague: “Just make this button work”. In my example all the requirements would actually be figured out bit by bit over months, nevermind the prescience required to foresee future architecture-breaking features or scaling requirements. At least you can make a mockup and get instant feedback, flawed as it is.
On either side it takes experienced engineers to suss out actual requirements from customers/PMs. The main difference is that the backend (especially on the infra/devops side) is only accountable to itself if everything goes well, but ironically that means no-one knows or cares about the amount of engineering that goes into keeping PMs blissfully ignorant of the risks and complexity.
Hahah, well as a primarily backend developer, that’s what I think as well.
“Just make this button work”
If that button doesn’t work, that sounds like a frontend problem to me… ;)
But yea, as you mentioned, it probably comes down to experience. As the meme from this post depicts. When I dabble in frontend and make a WinForm for my devtool, people just look at me and are like “Uhhh, can you make it better?”
No sir, clearly I can not. And I have no idea what you mean with “better”.
Yeah if you have shitty UX people frontend will just built what they’re told. Or actually more often, you could have really talented UX people and management decisions are like “needs more buy now buttons, the 3 visible on the screen aren’t enough.” Shit flows downhill
Man, if only backend demands were algebraically tractable. Often they’re related to frontend demands that may or may not make backend sense, since the frontend is all users see.
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.
Love it when my coworkers reformat the code style, making it nigh impossible to understand what they actually changed, while greatly inflating their “contribution.”
It also blows away the git blame, making it hard to know who actually changed that one critical line of business logic 3 years ago that you need to understand before trying to fix some obscure bug.
I have one coworker who does this constantly and if you just looked at git blame, you’d think he wrote the entire code base himself.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.