This describes a lot of software. No doubt. It's depressing and disturbing.
But not any of the systems I've worked on over 10 years. You may not get the absolute top salaries working on more meaningful projects, but there's plenty of them. Here are some examples that I worked on. To a fault, most of these places over-focused on the business and under-focused on exceptional engineering. Nonetheless, there's a lot of money to be made solving real business problems.
- Optometry practice management software
- Insurance benefits processing and customer service systems
- Professional soccer/football training iPad apps
- phone/pbx, Audio and video communcations, tie in with the web
- mapping systems to evaluate water scarcity and agriculture water use
- government benefits systems
Again, user Nextgrid isn't wrong. If you're willing to take say, up to 90% of the highest salaries available, rather than only the top 10% of salaries, there are huge amounts of non-advertisement problems to solve. Rightfully, this comment exposes the depressing cynicism which develops when building manipulative software.
In most all the systems I have worked on its more about screwing the user from a technical perspective than a deliberate business action, though there have been some of those too.
Either way it all comes down to some combination of mental laziness and no ethics. There is no ethical code, that I am aware of, for writing software.
* People (only software developers on security) who self-admittedly have no education, no experience, no credibility, and no practice of the art find themselves subject matter experts and cannot understand why an actual expert would disagree with their hastily formed opinion: https://news.ycombinator.com/item?id=22868620
* Hiring software developers is still somehow an arcane mystery few people can objectively figure out.
I have never seen anything remotely close to that in a place of corporate employment ever. I have been doing this in the corporate world since 2006, but if you count my time as a security analyst in the military than I could push that date back to 2001.
The military does force feed you (memorization verbatim) ethical standards, though, at a huge contrast to the loosey goosey corporate world:
Hiring is hard even in places where everything is quantified, such as baseball! Only a few teams have consistent success signing good value contracts even with all the statistics available.
Baseball is a bit different because there is only one winning team. Those people can still all bat (or whatever) much much better than the average qualified electrician can wire. But the point is that the average qualified electrician can wire. Whereas with the average programming interview candidate it seems to be a bit of a lottery.
JavaScript developers can't interface to the browser
I'm not sure I've worked directly with anyone recently who could pass a DOM test like that. Everything is React and and Axios and the browser (and HTTP, TCP, DNS, etc) is a mystery.
Edit: mystery isn't even the right word really, if you mention any of the other layers I've seen people get actually hostile.
From that particular post, this line stuck out to me:
Only 3 candidates were able to pass this code filter. The people that did pass either did well enough to pass or extremely excellent. The people that failed, maybe 19 of 22 people, all failed epically.
In practice I highly doubt that the population of candidates is actually this bimodal. It might lean heavily below the hiring bar, but I have trouble believing that it's bimodal.
My own personal experience has been that it looks a lot like a normal distribution where the hiring bar is just two standard deviations above the mean (which would imply that you give offers to about 1 out of 25 people who apply, which sounds approximately in the right ballpark).
As a consequence, if your question is producing bimodal results, I can't help but wonder whether it's a good interview question, because knowledge tests exhibit much of the same type of distribution of outcomes.
In my experience, if you give the candidate only one hour, access to documentation only helps with recalling past experience, because one hour is too much time pressure to actually calm down, pick through, and digest documentation on something you haven't seen before. If you knew the DOM functions existed and just needed their names, it'll work, but if you're unfamiliar with what the DOM already offers, even if you could learn it fine on the job, you won't learn it fine under time pressure. I recently adjusted one of my interview questions specifically to reduce the need for looking up documentation because I noticed exactly this phenomenon.
It surprised me just as much. I cannot speak to the capabilities or thoughts of any given candidate. Ultimately the test was a test of using a single standard API that is based upon a standard model. If it were just a matter of instructions or syntax I suspect a candidate would gotten over that by either asking the right questions, trial and error, using a reference of whatever. I think what really destroyed people was a complete inability to perceive the page as a series of nodes all interconnected with various relationships.
> In my experience, if you give the candidate only one hour, access to documentation only helps with recalling past experience
That is only partially true in this case, because the candidates knew coming in they would have a code filter accessing a page using vanilla JavaScript. I cannot remember if I specifically mentioned refreshing on the DOM methods or not. I might have. This was 8 years ago. But they had at least a day prior notice to catch up on how to interact with a web page using JavaScript using only their code. The time pressure would have applied to the specific tasks asked of the candidates.
I think what really destroyed people was a complete inability to perceive the page as a series of nodes all interconnected with various relationships.
Fair enough. :) I've experienced a similar issue with interview questions where they often floundered on the question because they hadn't ever spent time digging under the surface. For example, I notice that a lot of (typically junior) developers seem to only think of JSON as a representation for hierarchical objects but never really spent time thinking about the typed-ness of its keys/values or the limits of what JSON can actually represent. An interview is a bad time to be confronted with that realization.
I cannot remember if I specifically mentioned refreshing on the DOM methods or not.
Well, it was a long time ago, so I'll give you the benefit of the doubt and just talk about what I've experienced. I go back and forth about how specific I should be about the type of questions I might ask. On the one hand, it seems kind of foundational that someone writing web frontends is aware of the DOM and how it works, even if they never directly interact with it. On the other hand, I think questions need to control as much as possible for the "preparation" factor because some people simply interview better or have more time to study.
It doesn't seem too crazy to me today that a competent FE dev these days might have spent their whole career in React, and therefore they don't really have a strong grasp on the DOM. If you had asked when I first started doing web FE development, that would have been crazy! But frameworks got a lot better and a lot more comprehensive since then.
I recently had an interesting experience asking a question involving dealing with UTF-8 encoding. I figured "everyone knows about UTF-8 right?" I retired the question pretty quickly once I realized that bit manipulation is not actually something you have to be even remotely familiar with in order to be a functional developer today in the vast majority of programming tasks, and therefore it wasn't even a good fizzbuzz-type test.
Yeah, I have an in-depth knowledge of the imperative DOM APIs, but I can't remember the last time I actually needed to use them in my day job. React provides a very good abstraction that one doesn't need to break out of very often for a lot of work.
As someone who worked in the frontend space, and now doesn't, I think this has much to do with the fact that "anyone can learn to code" but often don't have any formal background. Lots of bootcamp grads, lots of people hearing about fat programmer salaries trying to get into the industry, people completing udacity courses and throwing buzzwords on their resume.
My experience in frontend feels like everyone learns ad hoc without digging deep into basics. Overall, I felt if you have aptitude or real passion for the work, you would just get a computer science degree and be attracted to other parts of the stack or other problems to solve.
This obviously doesn't apply to large tech companies which make it a point to hire talent (frontend, backend, whatever).
> Hiring software developers is still somehow an arcane mystery few people can objectively figure out.
This is actually one space where I feel the frontend world shines. Almost every frontend interview question has been very practical.
So this is a philosophical argument, but lots of those industries indirectly screw their customers. Optometrists who sell frames generally sell brands from companies like Luxottica who have made eyewear really expensive. The entire insurance industry is one of the major reasons healthcare is expensive and ruins the experience people have with patient care. All of this various from country to country of course.
I could go on, but sometimes your choice is working on a product that either screws the users directly (e.g. ads) or indirectly. Take your pick of where you want to draw the line.
That’s an unfair conclusion. Those examples were pretty specific and I, at least, see no reason to generalize (except maybe the insurance one), except perhaps along the lines of “serving exploitative monopolies is bad”
What I meant is that you can find an example in nearly every business of some person (or group of people) getting "screwed over", which is of course subjective. So subjectively, you could make the case that every business is "exploitative" (like the other replier who claims every capitalistic business is exploitative).
In fairness, there is no ethical consumption under capitalism. If you take that to its logical conclusion, then there is no ethical software development that supports capitalist endeavors.
If you take what I said to the logical extreme then sure.
What I was trying to say was that it's very black and white thinking to say something like ads = exploiting users and healthcare = not exploiting users.
Since Facebook usually comes up when people talk about unethical companies, let me use them as an example. Let's say there is a team that improves ad targeting by 5%, helping to reduce the number of irrelevant ads people see. Let's say there's another team that reduces data center electricity's utilization by 5%, which helps the environment.
Is the ad team more or less ethical than the data center team if they are basically both supporting the same end goal?
I don't work for Facebook if that matters. And I have no answers to any of the questions I posed above outside of my personal preference to not work in online advertising unless I need to do it to survive.
Luxottica is an unusual case. Most monopolies aren't that durable and Luxottica has challengers now. Also, the law in the US which says you can't buy glasses unless you have had an eye-exam in the past year is an anomaly amongst nations.
The functionality delivered by products is not screwing people unless you're talking about surveillence capitalism ala Google et.al. Capitalism and the pricing of goods is how we incentivize people to bring things to market and more importantly how we allocate resources. No one, anywhere, through any scheme has ever replaced the market for performing these functions and thereby driving civilization and invention forwards.
People keep believing they can (socialism/Venezuela), or give up on the project entirely after decades of trying (communism/ China / Russia). Maybe one day someone out there qwill have a genuinely new idea which works. Until then you have a right to feel good about contributing, in whatver little customer support / feature adder / managerial capacity you do, to the forward progress of society generally and the amazing, rocket-like increase in wealth absolutely everyone on this earth is experiencing relative to the past 30,000 years.
You've done well to stick with these things, and I do agree with your point, but I think almost any company can fall afoul of these practices...
- Optometry practice management software... targeted at maximising in-store sales with prescriptions that are difficult to use elsewhere, encouraging dark-patterns in sales tactics, etc.
- Insurance benefits processing and customer service systems... that attempts to minimise payouts, potentially by adding burden on the customer through the customer service process.
- Professional soccer/football training iPad apps... arguably sports doesn't bring as much benefit to the economy as equivalent spending elsewhere.
- phone/pbx, Audio and video communcations, tie in with the web... for premium rate phone lines that users with little choice are forced to use, such as those installed in prisons in the US.
- mapping systems to evaluate water scarcity and agriculture water use... for Monsanto.
- government benefits systems... that optimises to minimise payouts or contains unnecessary checks and hurdles.
These are great points. I'm reminded of a comedy TV show, The Good Place, where it turns out nobody has gone to "heaven - the good place" for a long time because there are too many unintended consequences of a person's actions. Buy an organic bamboo T-shirt? The company dumped waste into river. Vegan? You produced a bunch of single plastic plastic packaging.
It highlight the need to be diligent in daily decisions day-by-day. And when working somewhere that's doing something borderline, or totally unethical, working to move it in the right direction. I hope I can be aware enough to create a net benefit. The problem is knowing enough of the consequences of any action to evaluate if it's a net benefit. That's really hard, but I have to believe that toiling away _trying_ to make net positives happen will _actually_ result in net positives happening. Doubting I could ever make net positives happen leads to cynicism and ensures nothing good will come of my work.
(and thank you for bringing up point about benefit systems - that's the next gig for me, I will work to not be part of the problem)
Nice one. Just think about the user/consumer in any of these things. Does the thing I'm building help them, or only help the company I'm working for?
Be pragmatic. If the company provides a good service but doesn't survive, then that good service no longer exists! Some amount of optimisation for sales is likely necessary, but I think there's a line where things turn user-hostile, even in subtle ways.
Curious, how do you get jobs/contracts around these examples? My understanding is that most of these industries already have the talent they need (or have a preferred supplier they work with).
I freelanced for a few months for a local high-end cabinet maker. I helped them integrate their online ordering system with the automated fabrication equipment. It was, by far the most I have ever enjoyed programming. Coordinating with super skilled crafts-people to help them eliminate the redundant parts of their work was just so cool.
And by weird coincidence to this post I've recently been browsing around trying to find any other type of traditional businesses looking for equivalent help. But I've mostly found boutique places that wouldn't have need for a full-time developer.
Any tips on places to look for opening greatly appreciated.
I had a similar gig where a small local business wanted to integrate their Shopify store into their existing Django app. It was very easy and no BS to deal with like Kubernetes or Javascript build pipelines.
The problem is that I find it very hard to find these businesses, and indeed most of them don't actually have enough work to fill more than a couple of days so you would need a reliable source of these gigs if you want to survive (you can't charge insane amounts to compensate either as these businesses just can't afford it).
That type of work is too infrequent for most companies to justify hiring a dedicated developer.
You should work for a system integrator if you want to do that kind of work with regularity. The integrator contracts you out to those companies as needed, and you develop a niche and maybe customers start asking for you by name. In the best cases the integrator is your employer and offers full benefits, as well as absorbing the costs of downtime.
That business model can also be abusive for obvious reasons. I can recommend a good company if you're interested.
“Up to 90% of the highest salaries available”? I’ve worked on one of these and you’re more likely to get 60-70% of what you could otherwise be earning in some mediocre fintech company, let alone top salaries. Which is a much harder sell for most people.
But not any of the systems I've worked on over 10 years. You may not get the absolute top salaries working on more meaningful projects, but there's plenty of them. Here are some examples that I worked on. To a fault, most of these places over-focused on the business and under-focused on exceptional engineering. Nonetheless, there's a lot of money to be made solving real business problems.
- Optometry practice management software
- Insurance benefits processing and customer service systems
- Professional soccer/football training iPad apps
- phone/pbx, Audio and video communcations, tie in with the web
- mapping systems to evaluate water scarcity and agriculture water use
- government benefits systems
Again, user Nextgrid isn't wrong. If you're willing to take say, up to 90% of the highest salaries available, rather than only the top 10% of salaries, there are huge amounts of non-advertisement problems to solve. Rightfully, this comment exposes the depressing cynicism which develops when building manipulative software.