When you bill by the hour, what you’re really saying is “I have no idea if what I’m doing will have any value, and I honestly don’t care — all that matters is that I am not exposed to risk for even a single minute of my time working for you. I get paid for every minute.”
Yes, that's the point. As a software freelancer you have no responsibility to take on risk for a client company that you have no ownership in. You'd be a fool to do otherwise.
Every hourly billable contract I've signed has included a detailed scope. Contracts that very clearly delineate responsibilities and compensation. Both parties are agreeing to the value the freelancer is providing. You'd be a fool to hire a freelancer without understanding the value they provide. And as a freelancer you'd be a fool to sign a contract without clearly defined responsibilities.
The author seems to believe the method of compensation determines the value provided. But these things are orthogonal. I've worked with multi-million dollar agencies that bill by the hour. They provided a lot of value, they knew precisely the outcomes they were responsible for, and delivered those outcomes.
Blog posts like this come along every so often, usually when a freelancer discovers that there are circumstances where they can make more money on a fixed cost contract. For instance "This project will take me 40 hours. If I charge $100/hr I'll gross $4000 total. Or I could quote a fixed cost of $5000 total, and net an additional $1000".
The downside is estimating software is hard, mostly because the end product is almost always a moving target. Generally speaking, clients have a good idea of what they want. But "what they want" almost always changes as a project progresses.
The upside for the freelancer is that if the scope can be nailed down, and a client is predictable, a fixed cost model allows the freelancer to capture any additional value/profit from their productivity.
Which is why savvy businesses are fine with paying hourly rates. They want to fully capture the value of the freelancer's productivity.
In my experience, from a freelance point of view, it tends to be a wash. There are many fixed cost projects where you will come out ahead. But there are always projects with tons of scope creep, and cost increases are almost always more difficult to negotiate on fixed cost contracts. But YMMV, and there's no single correct answer.
In this particular case the author is using a controversial headline to drum up attention for his business, which he plugs about 2/3rds of a way through the article. I think web developers in particular are more familiar with SEO and web-based sales and are more likely to write about software in an attempt to funnel eyeballs towards their software business ventures.
Jonathan Grey, a current US intelligence official at the National Air and Space Intelligence Center (Nasic), confirmed the existence of “exotic materials” to the Debrief, adding: “We are not alone.”
...
Grusch said it was dangerous for this “eighty-year arms race” to continue in secrecy because it “further inhibits the world populace to be prepared for an unexpected, non-human intelligence contact scenario.”
“I hope this revelation serves as an ontological shock sociologically and provides a generally uniting issue for nations of the world to re-assess their priorities,” Grusch said.
A conspiracy spanning the better part of century should have more high-level whistleblowers than Grusch and Grey. If their claims are proven out the names Grusch and Grey will be immortalized in history. We still talk about the Gutenberg printing press. Centuries from now people will still talk about Grusch and Grey, and how they kick-started a new era of human knowledge.
Are we to believe that over the course of eighty years, comprising hundreds if not thousands of individuals, many of whom would have access to the same documents and materials, not a single one of these individuals, motivated by either honor or ego, decided to make this world historical disclosure?
The story seems engineered to appeal to the conspiracy theorist. A brave iconoclast bucks the system and exposes a massive coverup - a truth that just happens to confirm all the poorly sourced and speculative claims made by the true believers. Wait, why haven't we seen any miraculous technology derived from alien tech? Ahhh, this tech exists, but it's hoarded by a secretive cabal who may or may not themselves be aliens/reptiles or blood-drinking elites. Etcetera, etcetera.
On the other hand ... it would be apropos if bureaucratic inertia led to a world-shattering disclosure. And the conspiracy theories could be 95% b.s. and 5% truth.
For all those reasons I'm not really convinced. Are Grusch and Grey convinced because the evidence is that overwhelming? Are they seeped in online UFO conspiracy culture, and reading a very slanted interpretation into the intelligence documents they have accessed? Are the analyses the military has run on any recovered materials sufficient to determine an origin in non-human intelligence? Have any experts outside the military examined and tested these materials? Does there exists genuine recovered craft ala Independence Day or are the "craft" large meteors that, if you squint, kind of look like a spacecraft? Have they recovered biological material?
Ultimately we won't be able to make a true determination until we get some actual evidence. First, reviewing any documents that supposedly contain these extraordinary claims. Second, interviews with other intelligence officials who have spoken with Grusch and have had access to the materials. Third, getting these materials into the hands of relevant experts, to determine if non-human intelligence is the most likely source.
> I see this argument pop-up frequently when taking to design leaders or developers. I call bullshit on this excuse. You absolutely have the choice to avoid implementing bad designs - that's your job! Either you're not fighting hard enough against those pushing for it, or you're just trying to build a "pretty" portfolio.
sigh I'm so tired of this absolutist, ranty way of thinking. Its indicative of Twitter-brain or social media outrage brain. Design is almost always a collaborative process. You literally have no controlling choice on the outcome, because the choice itself is being made by multiple stakeholders, be it your customers, your coworkers, your clients, etc.
Also, the author lists himself as the "UX Designer & Front-End Engineer @ Donorbox." Their web site at https://donorbox.org appears to be using a hamburger menu on mobile. I hope he isn't beating himself up over it.
It's hard to move away from established UI patterns like a hamburger menu because stakeholders expect it, and I suspect users look for that little hamburger icon as well.
when the did anyone start expecting a hamburger menu? all these old websites i used to poke clearly labeled buttons on all of a sudden have three lines one year. its like all these web3 node js assholes took over the planet within an 18 month cycle and brainwashed everyone.
im old. i expect buttons with words on them.
now i have to spend a significant amount of my time, hours per year, explaining to users to click the "thing with the three lines, then scroll down, there should be a menu that says XYZ, no, you have to go down farther, its between PDQ and ABC. no its not categorized very well i agree. i agree nobody would know what three lines mean. ".
>It's hard to move away from established UI patterns like a hamburger menu
>when the did anyone start expecting a hamburger menu? all these old websites i used to poke clearly labeled buttons on all of a sudden have three lines one year. its like all these web3 node js assholes took over the planet within an 18 month cycle and brainwashed everyone.
That's why it's really not established, nobody really wanted a hamburger to begin with when websites used to be able to afford to serve steak.
The appearance of such a non-satisfying menu item has always lacked the flavor that attracts patrons the most.
First, I actually like hamburgers! Probably prefer them to steak, to be honest - especially when cost is factored in.
The problem, as I see it: people went from nice useful computer screens to these tiny phones, with very narrow horizontal space. If you show up to a restaurant and can't eat steak, the smarter restauranteurs are going to adjust.
Some sites are able to figure it out, but lets not blame the proprietors for giving the people what they want: a horizontally tiny viewport for nav. If you use that space for nav, you don't use it for actual content - I'm sure people in this forum hate that as well.
> You absolutely have the choice to avoid implementing bad designs - that's your job!
Ha, seems like this someone doesn't know when and where to pick their battles. Yes, sometimes you can really push for change when you come up with a real, convincing argument. Or, A/B test the crap out of it.
When I was on the front-end of the stack, it really taught me "disagree and commit" often with product and design. Unless it's something existential, there's almost no reason to accept "good enough", move forward, measure, and iterate.
yeah this is an odd article. hamburger menus are not perfect, but they do the job and they’re expected by the user, which is important in UI
this article’s main justification for them being poor is that they don’t work well without a mouse and/or when you have javascript turned off. okay there are times and places and people for whom javascript will be off, that’s understandable, but still rare. who is browsing the internet with just a keyboard though?
they’re fixing an issue for the vanishingly few by worsening the experience of overwhelming majority, and acting as if this is an obvious solution that developers are too blighted to see
There are people that can't use a mouse and have to use keyboard navigation.
The negative attitude against towards accessibility vexes me greatly. Are wheelchair ramps a pointless waste of money because the vast majority of people can walk just fine? Should we not care about making cities safer for blind people because they are just a small minority?
These kinds of attitude wouldn't be socially acceptable in the "real world" but the web still likes to pretend that it is the Wilde West. And yes, actively excluding people from being able to use your services is a bigger problem than you site being slightly less pretty.
I don’t believe that you’re replying to the strongest possible interpretation of what I said. you’re replying to a strawman that you’ve allowed to make you angry
the point is that a ramp is of equal use to a non-disabled person as a disabled one. what this author wants is to make everyone use stairlifts
People with disabilities (mostly vision impaired) browse the internet with "just a keyboard" or a screen reader. It's quite cumbersome, but for some people, that's the best they can do.
At a previous job, we had to follow their extensive rules for making everything accessible. A few things that I can remember:
* minimum contrast ratio
* support for the high-contrast mode that some browsers have
* screen reader support for every UI element - this requires a ton of different things
* everything must be usable without a mouse
There were tools to check for a lot of this. There was a separate team of accessibility people who would check the result and create tickets for things that were not good enough.
It was annoying when the designers specified low-contrast colors, then we'd build it with the colors specified by the designers, and then the tool tells us the colors are unacceptable. Why can't the designers check the contrast ratio of their colors?
Testing with a screen reader was extremely annoying (because it reads a description of the currently focused item), but it gave me a lot of empathy for the poor people for whom this is the only way to use a web UI.
OP is working in a dysfunctional workplace and has conflated that with "developer estimates are bad":
> 1. Give a very wide estimate with a lot of padding
> 2. Get pressured to be more accurate and to bring the estimate down
> 3. Get pressured to work unpaid overtime to meet that estimate
> 4. Watch management get congratulated by upper management for running a tight ship
Imagine I had plumber at my house and he gave an estimate of 3 to 4 hours to replace a rusted pipe. And I responded with "I think it should only take you 1 hour". He would look at me like I was crazy. That's because trying to substitute my layman's estimate for a professional estimate is crazy.
OP is providing estimates - that's a reasonable ask. The problem is management is ignoring the professional estimate and using their position to substitute in their preferred estimate. OP is being used to launder management's expectations. So of course they're patting themselves on the back. If the plumber ignored his own professional experience and only charged me for 1 hour of labor I would think of highly of myself as well, even though in reality I had no idea what I was talking about.
The solution is to set estimates that you can explain and justify. If management ignores your professional opinion you need to make it clear it's their decision and not yours. If you don't respect your own opinion no one else will.
I think what is hard with a lot of tech is that developers are often not plumbers. We are not encountering similar sets of problems nor are able to use similar solutions or even refer to familiar tooling all of the time. It's more akin to when the plumber crawls below your house with nothing more than a flashlight, then recoils in horror that your sewer is plumbed in 200 year old rotten wood pipe, then they start digging and hit more pipes that aren't on any map and shouldn't be there, then things get expensive and timelines enter the unknown as the problem gets seemingly bigger the more of it that you solve. Of course the client never sees this, they think you just twist a wrench, so we have these deadlines and talented people burning out over the stress they cause them.
> We are not encountering similar sets of problems nor are able to use similar solutions or even refer to familiar tooling all of the time.
Frankly, yes we are. There’s only so many ways to solve a problem and there’s only so many problems to solve in a particular field.
A senior engineer should have had enough experience to at least have a high level understanding of what is going on, and to correlate that experience with approximate work. If that’s not possible, the work is just not scoped down enough.
A team of engineers, given their combined experience and business knowledge should pretty easily come up with a story point estimate based on existing completed work. And that’s the entire point of the refinement and estimation process: getting enough information about a piece of work, then working together to come to a decision on an estimate.
Will that be right all the time? No. But that doesn’t mean the value is useless, it provides plenty of information on if a piece of work is small, medium or large, as well as if it’s expected to take a few hours, days or weeks. And who better to come up with that number than the people actually working on the issues?
>There’s only so many ways to solve a problem and there’s only so many problems to solve in a particular field.
That is true today but not tomorrow. The field often changes. New ideas generate new ways to think of problems which require new experimental designs to solve. New experimental designs become possible with new technologies offering more resolution or fidelity. Entirely divergent technologies sometimes emerge which offer new metadata to compare with in the analysis, or change the context for other forms of analysis. What was cost prohibitive becomes cheap. All of this means you cannot merely write a few pipelines and expect them to be cutting edge forever. You cannot automate the very creative act of hypothesis generation. You cannot reliably develop an automated solution without first developing some sort of a test over a subset of the data or a simulated dataset, to ensure your solution to a given problem even has the power to resolve what you are expecting it to resolve.
The Big Bounce[1] hypothesis is a model that "suggests that we could be living at any point in an infinite sequence of universes". So while our current universe may not be infinite there may be some yet undiscovered infinite/eternal natural process that gives rise to universes.
Olber's Paradox[2] and the inability to reconcile it with our current astronomical observations seems to disprove that our current universe is itself infinite.
Strictly speaking, Olber's Paradox is about an infinite, eternal/static, and homogeneous universe with an infinite number of stars; in such a case, the light the dust absorbs would cause the dust itself to start emitting light, which would make it visible [0]. I'm not sure to what extent this paradox applies outside that scenario (e.g., an infinite-but-changing universe)
DoIT estimates the project will take at least 5 years to make the necessary changes resulting in a total state general fund cost of approximately $1.47 Billion .... Total Annual Cost $293,894,620
The Department states historically the cost of implementing a new application, whether replacing an existing application or implementing applications where none existed before, is three to seven times the cost of purchasing the software licenses. [1]
Do the people of New Hampshire believe so strongly in using non-proprietary software that they're willing to take on this extra cost? Is there widespread support and understanding of free or libre software amongst the population?
My experience has been that people have a transactional relationship to software, not a values-based one. Which is the main reason the various free software movements have yet to gain wide spread traction. People don't seem to care about how software is created and how it is licensed but whether it meets a particular need. (I need to file my taxes. I want to listen to music. I want to book a reservation, etc.) The challenge is not necessarily to "make software free" but to first get people to view software through a holistic, non-transactional lens.
The hurdle for this legislation will be convincing legislators to spend $1.47bn on a software replacement that doesn't add any additional features. I mean, are citizens really going to care that the web-based interface they use to file their taxes is no longer using proprietary software under the hood? If they're viewing software through the transactional lens then this plan will seem wasteful and non-productive.
Why? There could be better ways to implement, like just applying this as systems meet their natural end of life rather than rewrites. If we're fine with ideological legislation, then why not for other things?
It's possible the complaint is using a trivial example to illustrate the type of argument plaintiffs want to make during any trial. A 200-line example is too unwieldy for non-programmers to digest, especially given the formatting constraints of a legal brief.
Look at paragraphs 90 and 91 on page 27 of the complaint[1]:
"90. GitHub concedes that in ordinary use, Copilot will reproduce passages of code verbatim: “Our latest internal research shows that about 1% of the time, a suggestion [Output] may contain some code snippets longer than ~150 characters that matches” code from the training data. This standard is more limited than is necessary for copyright infringement. But even using GitHub’s own metric and the most conservative possible criteria, Copilot has violated the DMCA at least tens of thousands of times."
Does distributing licensed code without attribution on a mass scale count as fair use?
If Copilot is inadvertently providing a programmer with copyrighted code, is that programmer and/or their employer responsible for copyright infringement?
There's a lot of interesting legal complications I think the courts will want to adjudicate.
But ... the examples on the right are short, concise, and effectively communicate the problem. The left examples contain no actionable information, wasting the time and attention of everyone in the channel/thread.
Maybe working in an adversarial or dysfunctional work environment is what leads to misinterpreting a detailed message as hostile.
Or the team needs to learn to use communication tools effectively. Slack messages should be concise. But a bug report doesn't always fit neatly into a few lines of text. Use an issue tracker for detailed reporting and Slack/email for informal conversations.
Either way the point of the blog post stands - everyone needs to communicate clearly and avoid ambiguous language. If I send an ambiguous message to 10 people, I've just increased their mental overhead and frustration, ultimately distracting the team and slowing them down. Instead, I should take a moment and try to look at it from their point of view and try to communicate what they need to hear and not what I want to say.
> So, Middle Earth had coal, but did it need coal? I don’t think so.
The author focuses on energy sources for machine power. But what about generating high heat for metallurgy? Coal burns longer and hotter than wood, and releases fewer particulates. Also coal is more energy dense than wood, making it easier to transport.
Yes, that's the point. As a software freelancer you have no responsibility to take on risk for a client company that you have no ownership in. You'd be a fool to do otherwise.
Every hourly billable contract I've signed has included a detailed scope. Contracts that very clearly delineate responsibilities and compensation. Both parties are agreeing to the value the freelancer is providing. You'd be a fool to hire a freelancer without understanding the value they provide. And as a freelancer you'd be a fool to sign a contract without clearly defined responsibilities.
The author seems to believe the method of compensation determines the value provided. But these things are orthogonal. I've worked with multi-million dollar agencies that bill by the hour. They provided a lot of value, they knew precisely the outcomes they were responsible for, and delivered those outcomes.
Blog posts like this come along every so often, usually when a freelancer discovers that there are circumstances where they can make more money on a fixed cost contract. For instance "This project will take me 40 hours. If I charge $100/hr I'll gross $4000 total. Or I could quote a fixed cost of $5000 total, and net an additional $1000".
The downside is estimating software is hard, mostly because the end product is almost always a moving target. Generally speaking, clients have a good idea of what they want. But "what they want" almost always changes as a project progresses.
The upside for the freelancer is that if the scope can be nailed down, and a client is predictable, a fixed cost model allows the freelancer to capture any additional value/profit from their productivity.
Which is why savvy businesses are fine with paying hourly rates. They want to fully capture the value of the freelancer's productivity.
In my experience, from a freelance point of view, it tends to be a wash. There are many fixed cost projects where you will come out ahead. But there are always projects with tons of scope creep, and cost increases are almost always more difficult to negotiate on fixed cost contracts. But YMMV, and there's no single correct answer.