These are my personal opinions about programming. These options aren't are based upon personal observations.
- How to Hire Developers
- Curse of the Expert
- Why Software Fails at Hiring
- What Makes the DOM Challenging
- Programming and Sex
- Why JavaScript Needs Frameworks
- How to Promote
- How to Retain Super Competent Developers
- How to Train Developers
- How Education Factors Into Software
- Performance
- Software and Ethics
If a business wants to select the most ideal candidate from a given pool of potential employees there are simple things to do. First, know exactly what you want. As somebody who has interviewed a lot most businesses have absolutely no idea what they want from a developer. For example a full stack developer will write some services or define some APIs and jump into the front end if the front end developers need help, but its all extremely vague. If you don't know what you want, as specifically as possible, you have no idea how to achieve candidate selection, because you need to have known goals to properly separate candidates aside from bias.
Here are some examples of specificity:
- Define a practice of test automation and enforce it with using a scheme of continuous integration.
- Define performance targets and the means to measure such.
- Define internal APIs as integration points between separately constructed applications and/or data systems.
- Put dynamic text on screen.
Second, make a determination about the minimum intelligence required to achieve the desired tasks. Then test the candidates for intelligence. Candidates that lack the necessary intelligence to achieve the desired tasks are immediately disqualified. No subjective technical assessment is required, but recommended only to determine level of experience and areas of interest. This is the number one area where most businesses fail.
There is no compromise on the issue of minimal required cognitive competence as doing so will result in a greater investment of accommodations than that future employee will ever return to the business. We were able to measure various incidents of this when I was at Travelocity, most of which involved introducing use of jQuery where such usage introduced considerable product harm in production. The increased costs associated with accommodating to employees that are incapable of performing their designated responsibilities are not immediately obvious. Many of these costs are economic in nature and are passed directly to lower product quality and increased external liabilities.
It is ideal to find the perfect candidate who is currently performing all specified tasks for some other employer using your technology stack so they can immediately solve world hunger on day 1 of their employment. That's not going to happen. Instead a person smart enough to perform the specified tasks will figure them out provided the opportunity and sufficient time to write the necessary corresponding code.
Third, don't let developers have any part of the selection process of other developers. This imposes a bias the business can never recover from. Some developers are able to identify these biases and select candidates in an objective manner, but most will fail miserably in this regard as most people are incapable of recognizing bias on any level. In my personal experience interviewing objective selection criteria conducted by developers occurred about 1 out of 12 times. So don't do it. Objectivity, by the way, requires uniform measures that are relevant to the hiring goal, as opposed to that which is familiar or comforting to the developer performing the selection. Instead keep bias where it belongs: at the stakeholders. Stake holders include hiring managers, product owners, higher leadership, and so forth.
An expert is somebody with maximum confidence. Confidence is an internalizing quality grown from thoroughly repeated trial and error. Contrast that to arrogance which is an externalizing quality based upon a projection of the self that may not align with confidence or capability.
The problem with experts is that they know, with near certainty, what is needed to achieve success in a given task that aligns with their prior practice. They know because they have failed at that task many times and achieved success sufficiently enough to identify what separates the successes from the failures with precision. Experts are excellent when you, as the hiring manager, identify a problem and the experience of the expert candidate closely aligns with that problem.
In most cases software developers are disposable cost centers to a business. When an employee is deemed disposable and/or temporary they achieve a subordinate status in the hierarchy of the business. Irrespective of their compensation, intelligence, competence, and even their external credibility, it comes down to "What can you do for me?.
In an environment where developers are inherently subordinate tools experts are likely to be perceived as a point of friction or social challenge even if as a person they measure high on agreeability. If as a candidate you are an expert you will be out of alignment with the hiring expectations of a business. That is problematic, because if the candidate is in fact an expert, the business won't know how to evaluate them or qualify their competencies, which repositions the candidate to the low end of the bell curve despite proven prior experience. That is compounded by the insecurity of the hiring team and how closely the goals of the business align to the job. For example a company that sales software solving an original problem cares much more about the competency of their developers than does a company that sells advertising and will evaluate prospective developers accordingly.
If you are an expert you have two choices when looking for a job. If you want to maximize your probability of selection the goal is to fall into the middle of the bell curve, which means suppressing your expert knowledge and mindlessly following the same trends invalidated by your expertise. That is miserable and likely humiliating. Most experts I have met would rather be unemployed, so this really only applies as a matter of extreme desperation or of strong compromise. For example an expert may take a job of lower stature, capability, and compensation if such a job provides maximum unallocated time for the expert to work on personal goals.
If, as an expert, you want to maximize your potential compensation or ability as a non-equity salary employee you need to brace for frequent failure. You will fail at hiring often, because the need for experts is rare, especially in software where most businesses don't even know what they want from a developer at hiring time. Worse, many business don't how to define product quality the way an expert does and doesn't care. As a potential candidate, likely even as an expert employee, you will not convince them because they are strongly disinterested. So, brace for frequent rejection.
If you want to increase the probability of selection as an expert you need external credibility. External credibility provides a form of social validation. Most people fear evaluating something original, something that is more than the sum of their prior experiences, and social validation allows hiring teams to differ those evaluations onto strangers at no cost, even if invalid.
External credibility is a tough challenge for software developers. Typically the people that are experts, especially in software, are introverts busy building stuff in contrast to extroverts that give talks at conventions. Time and energy spent socializing is time and energy not spent solving original technical problems. What I used to do for external credibility was claim a prior project achieved 5 million NPM downloads, which I regarded as a fairly weak signal, but it worked well enough for hiring.
Hiring software developers is a self-inflicted mortal wound of business. There are no agreed upon conventions, credentials, education, or any other factor that determines competence in software. That lack of agreement is an indication of immaturity, faulty expectations, and bias.
Other industries have solved this problem. For example there exists a common set of credentials for teachers, real estate agents, doctors, lawyers, truck drivers, police, fire fighters, electricians, and so forth. In any other industry if a given person lacks the minimum required credentials they cannot work for anybody at all. No excuses. This sets a common minimum baseline of competence, ethics, and accepted practice.
Business appears to not want to solve this problem as software developers are typically viewed as a disposable cost center to the business. That means a business is certainly not going to directly invest in the advancement of a developer's technical education unless a regulatory action or contractual obligation requires otherwise. Developers are also viewed as lacking loyalty and willing to switch employment frequently. Developer can expect to achieve a 20% raise by switching employers every two years for the first decade of their career while only gaining perhaps a 3% raise from remaining loyal, so there is no incentive to retain developers or invest in them.
This hiring problem is the result wanting the freedom of maximum selection from among a group of applicants without concern for the specifics of what you want to select, which is uncertainty avoidance. You cannot have your cake and eat it too. As a result software hiring is often a race to the bottom with low retention that results in over paying for the least qualified applicant.
In the fewest possible words: choice. In relational models the path between two points is a series of segments between the various nodes that comprise the path. At each segment a choice must be made as to which path to take to creep closer to the destination. A person with insufficient cognitive ability can handle one or two choices but beyond two nodes in the path they get lost. The computational overhead to successfully navigate by forming a series of independent decisions at each node is overwhelming.
From a behavioral perspective this is an incredibly intriguing field of study because most people do not possess the executive functioning to think in this manner. What's more interesting is that it isn't directly associated with brain size or intelligence. Social insects like ants and bees, for example, perform exceedingly well at this. Tool using birds, especially ravens and crows, and also perform well at this. In some cases these other animals can perform better than many people.
The most interesting part of this is what makes the smart people different, because it isn't computational capacity as you might expect. Instead the difference primarily comes down to speed of executive functioning, as in how fast you can make an arbitrary decision, and the ability to regard each of these decisions as arbitrary and potentially wrong. Perhaps apathy is a good description. For these people there is little or no regard to the correctness of an arbitrary choice. We can call this a no cost decision. If a choice moves the person closer to the destination the choice is good and no further thought is given. If a choice moves the person further from the destination the choice is bad and hopefully the next choice is better, but if not they must backtrack one or more steps. Each decision is formed in relative isolation with little care. There is almost no critical examination performed until the destination is reached, at which point maybe the person will review their path to become more efficient the next time.
Now compare that back to the people who cannot perform. Each decision is examined in much greater depth against a series of cost/benefit analysis considerations. We can call that a high cost decision. Each decision is expensive and worse the weight of a former decision remains into the next decision until they become emotionally overwhelming, as if being crushed by an emotional debt.
Thinking about this abstractly it doesn't appear to make sense because this entire process of thought exercise is so trivial and not associated with any consequence. It is different, though, at programming time when you must write the instructions and carefully consider how this works instruction by instruction. At instruction writing time the perceived consequences of an incorrect approach are perceived as very real, because there is there is an emotional burden that builds with each instruction.
If you are smart enough to consider from a variety of choices extremely quickly and not care how wrong each choice is in isolation there is no emotional burden and insufficient perceived penalty. After a few hours of practice the patterns of navigating the tree models at hand become well known, mastery sets in, and confidence is achieved. If should be noted this mode of behavior extends well beyond the DOM towards a variety of real world scenarios, often considered visual abstract modeling. Advanced visual reasoning capabilities are also associated with certain childhood learning disorders such as autism, dyslexia, and dysgraphia.
Other situations in which these behaviors apply: land navigation, visual abstract pattern analysis, original tool creation, threat modeling. Further interesting is that each of those other listed skills are closely associated with basic soldiering skills but not associated with formal education or academics as those are commonly perceived. It must be quite frustrating when some dumb infantry soldier can spontaneously master this primitive programming skill after just a few hours of practice while many formally educated more intelligent programmers are permanently incapable of grasping this capability.
It shouldn't be frustrating though or a surprise, because this isn't directly reflective of intelligence. Incompatibility is directly correlated with neuroticism, which is has no association with intelligence. This is measurable and compatibility is highly predictive. To say that many developers are incompatible with something like the DOM is to directly assert that many developers are some degree of measurably neurotic. Scoring low on neuroticism, associated with calmness and low negative emotion, achieves higher compatibility with a multistage decision matrix like the DOM. That statement is absolutely true for males, but less so for females. More on that later.
These are the people that appear to barely have a pulse even under intense external environmental stress, such as remaining serenely calm under intense pressure, and despite the intensity of those external pressures continue to function cognitive clarity. It doesn't mean these people are immune from fear, as fear executes in a different area of the brain separate from other negative emotions. Instead it means these people are not distracted by fear and if the fear is enough to trigger endorphin and adrenal responses they actually become more intelligent in the face of fear. If you want the best front-end developers, and at a bargain price, hire unnaturally calm people off the street that are at least minimally intelligent enough to learn to code. Yes, people off the street will require training and education time, but that is the cost of talent. Most businesses do the opposite only to be hopelessly surprised the quality of work is garbage and the developers responsible for that garbage are extremely narcissistic when assessing responsibility. That narcissism is exceedingly more common than in a natural social environment, because redirection is a survival mechanism of the grossly incompatible.
In psychology there are measured cross-cultural differences between the sexes. Females rate higher than males in both agreeability and neuroticism. Males rate higher in assertiveness and conscientiousness.
This is interesting because in the prior section I specifically mentioned that for male front-end developers the primary predictor of success after intelligence is low neuroticism. If females regularly score higher than males in neuroticism then, all other things being equal, should achieve a lower predictor of success compared to a male population, but this isn't the case. The section above was specific to tree models and abstract relationships generally and the DOM specifically. In my experience females are substantially less restricted in navigating tree models compared to males. All that means is that success is more clearly identifiable and predictive for male candidates as front-end developers while female candidates present a lower risk of failure on the low end of competence and are less identifiable of predictive success on the high end.
I don't know why female performance is different than male performance in this narrow slice of programming. My completely uneducated and utterly baseless assumption is that females achieve a greater non-cognitive self-awareness that allows for increased neuroticism with minimized cognitive distraction, a capability less well developed in males. This could be due to differences in neurophysiology. Female brains are measured at masses equivalent to male brains but in a measurably smaller volume indicating higher density structures. Female brains also have a substantially wider inter-hemispheric bridge that may allow parallel processing capabilities that are less developed in males.
Males, on the other hand, are measured having a negligibly increased spatial processing capability compared to females, but dominate on spatial processing evaluations compared to females indicating a male preference, almost to the point of singular reliance, upon spatial processing for problem solving. That is convenient to solve for a variety of abstract reasoning problems, but it also presents as a single point of failure. It's among the most expensive (tiring) of thought exercises. Females preference spatial processing less than males, which is less exhaustive, but may present as slower reasoning on problems best solved by spatial reasoning. This is actually already measured in psychology, but I think its unfair to measures of female mental performance. Females tend to preference low cost thought exercises to solve problems first, such as memory recall. While tests of spatial performance preference males, I suspect if provided a wide distribution of real world cognitive exercises spanning hours that females would be measurably less exhausted (extremely so) than males at the conclusion of evaluation. The importance of that distinction cannot be understated in a field like programming where tough problems demand intense mental concentration that simply does not exist during moments of fatigue.
Regardless, I have not discovered any research or identified any self-observations that indicate one sex performs better at programming than the other, either in general or upon specific task evaluation. It seems the greatest discriminator for programmers is intelligence and that factor applies equally to the sexes. Females are a minority population among developers, and if that isn't a result of capability its a result of selection and/or preference. My strongest recommendation is to encourage more women to become programmers as this injects a greater diversity of problem solving capabilities. It increases the potential for success at zero cost and no increase of risk.
The glue that holds all things together on the front end is the Document Object Model (DOM). It is the backbone of everything in web browsers. The DOM is how JavaScript binds to markup and the thing that presentation addresses. A failure to understand the DOM results in a failure of appreciation of performance, accessibility, and some aspects of front end security.
Most developers are scared to death of the DOM. I mean horrifically terrified and would rather cut a finger off or switch careers for half the money. It is a phobia and its completely irrational. This is not a technology failure. It's a social failure of poor selection, faulty expectations, and inadequate training.
There are some reasons for this and none of those reasons have anything to do with technology of the DOM itself. Many developers will attempt to argue to the contrary and those arguments are extremely interesting from a behavioral perspective, but from a logical and programming perspective they are typically extremely weak. As a form of dark entertainment play devil's advocate and encourage a developer to voice their concerns about this matter as a form of agreement. Watch for what they are actually trying to say with their vocal tone and body language versus the logic they express.
First, front end developers are not properly trained by schools, businesses, boot camps, or just about anywhere else. That is a bad state of affairs for software. Developers that are smart enough to self educate and above the necessary cognitive threshold to understand the DOM and capable of measuring things will just figure it out on their own, but that is an incredible small subset of total developers. Some developers are above the minimum required cognitive threshold and have appropriate mentorship to learn and/or appreciate the technology, but that is perhaps even more rare, unfortunately.
Second, the DOM is a tree model. Tree models implicitly require a formal understanding of relationships as abstractions, which is highly imperative. There is a minimum cognitive performance, such as IQ, required to understand relationships as abstractions. The concept is astonishingly simple which leaves no room for a grey area. If you are smart enough to understand the concept it will only take a few hours to learn the necessary APIs and master the concept, because there isn't much to it. If you aren't smart enough learning this is a near impossibility.
This means the DOM, the glue that makes everything work, discriminates on the basis of cognitive performance. As described earlier cognitive performance for just the DOM is measured as any IQ above a specified minimum and exceptionally low neuroticism. There is much more to the front-end than just some minor DOM traversal.
For both business and practicing developers that is extremely problematic. Most of the work on the front end is a matter of displaying text on screen and trivial amounts of presentation or minor interactions. From a business perspective these requirements are assumed to be highly repetitive and low skill. Not as low skill as data entry, but certainly not skilled enough to write original software.
This is a problem. It isn't a technology problem as the technology works amazingly well and allows developers to create things that scale very efficiently. It is a business problem. More specifically it is a hiring problem. Actually, its a training and selection problem, but business wants this to be a hiring problem so that's what it is.
The business solution to this problem is not to hire smarter people as that costs more and smarter people expect more from the business requirements. Instead the business solution is an additional layer of abstraction, which directs something simple yet challenging to something profoundly more confusing yet primitive. This opens the field of participation to a far wider distribution of people and it allows them to build really complex things which is supremely empowering. The problem with that is that it economically substantially increases the cost of the product through excess processes, additional technologies, tech debt, advanced maintenance costs, slower enhancement/feature delivery, and so forth. The business is forced to assume those extreme additional costs or pass those additional expenses to their customers.
In most larger companies there are two separate paths of elevation:
- Management of administration, often referred to as leadership.
- Scientist, often referred to as a principle or technical fellow.
The managers typically become the leaders of the organizations who own administration, man power, and vision for an organization. Conversely, the scientists perform discovery, innovation, research, and risk analysis. Even the US military makes these distinctions with commissioned officers versus warrant officers. Both positions require extremely large amounts of work effort in order for a person to achieve success, but they require personality traits that are diametrically opposed.
To be successful as a manager of people/organizations you need an insane level of conscientiousness. Conscientiousness means an ability to perceive the world around you and all the numerous variables it comprises. Conscientiousness is often associated the factors of conservatism and administrative success such as dutifulness, orderliness, industriousness, patriotism, and various other rigidly perceived qualifiers associated with hard work.
To be successful as a scientist you need some level of passion and innovation, which are highly correlated with creativity. Creativity is highly correlated with openness, which explains why software developers with a passion for software are willing to continue writing software outside of work and generally prefer open source contributions. Contrary to conscientiousness, which is associated with conservatism, creativity and openness are generally associated with personality traits associated with concepts of liberalism. Scientist personality types tend to prefer transparency and precision as primary personality traits.
To be more clear conscientiousness and openness (creativity) are not diametrically opposed qualities. Each of those qualities are separate measured as 2 channels of the big five personality index in psychology and a person can measure high in both. While those two channels of personal are not diametrically opposed the resulting interests and preferences are frequently opposing qualities. As an example a person may measure high in both openness and conscientiousness which indicates a capability for exploration and awareness of many variables simultaneously, but if the person prefers exploration they will be less happy keeping their ideas locked away behind administrative concerns. Likewise a person that is more interested in orderliness and goal completion will be less happy innovating or exploring distracting ideas outside their primary goals.
People are not self-aware enough to objectively determine whether they are more creative or more conscientious, because those qualities are not oppositional. Self-evaluations are biased towards the work product performed and that bias is magnified by the commitment and work required to elevate a developer's skills and managerial prowess. As such developers worthy of promotion should be tested to determine how their interests differ from their capabilities so as to indicate where their interests more closely align to their potential and current capabilities. The conclusion of such testing should serve as a very strong guide for which path a person should elevate into.
A secondary factor to consider is that every organization has a greater demand for managerial leaders than it does for scientists. As such scientist type positions are more rare and more competitive. That means you must be substantially more intelligent than your managerial peers with an amazing ability to balance insane levels of objectivity, novelty, and creativity. A partial exception is the military where scientist types, warrant officers, are rare but the demand far out paces the available candidate pool almost guaranteeing early selection and promotion according to minimal acceptable criteria.
Retaining excellent developers requires far less effort than most businesses suspect. First, pay these developers at market rate. This is a challenge because market rate can change rapidly and increase drastically. It doesn't hurt to be transparent about compensation. If it becomes known that one developer earns substantially more than another developer it means either the business has made a fundamental flaw of personal judgement about their employees or that the business is more interested in retaining one employee than the other.
Second, give the developer challenging work. This work should feel exploratory and be filled with discovery, research, and and original effort to create something helpful. If the work is not advancing the technical capabilities of a top performer then they will go somewhere else that does have such work even if that means taking less pay.
When challenging work is not available then give this developer no work. A top performer will find things to do that are beneficial to the business or software at large. This sounds counter-intuitive, but super competent developers only achieved super competence by solving hard problems which requires initiative and insane amounts of practice. If these people cannot perform the practice they need they will go elsewhere and sometimes are willing to do so for less pay.
First, set the acceptable baseline extremely high. Product quality is a direct reflection of how high or low you define your level of acceptance. As such the acceptable baseline must be an agreement between stakeholders and technology leadership where technology leadership is making cost/analysis decisions about the personnel they have available.
Bear in mind that despite what many developers claim a high baseline will not result in lower developer productivity or slower delivery. Counter-intuitively a higher baseline will result in faster code delivery because developers will accept certain risks more directly opposed to offloading everything into a giant stack of dependencies each with their own concerns and risks.
The risk with setting the baseline of acceptable delivery too high is that it exposes the developers that were never really qualified to write that code in the first place. To be clear when quality and delivery standards are raised all developers will require some time to adjust. The developers that aren't qualified to perform are those who cannot make the necessary adjustments provided sufficient time and mentorship.
Once a high performance baseline is established it must be enforced. Automated enforcement is most ideal. Examples of automated enforcement include things like static analysis, test automation, thorough type definitions, accessibility checks, execution performance checks, and so forth. Automated enforcement is ideal because it does not show bias and does not bend to personal and emotional concerns.
On top of the automated checks there must also be code reviews. Automated enforcement will not catch everything. Putting a different set of eyes on code if often sufficient to catch issues the code author may have over looked.
Generally speaking education is defined as the following:
- A bachelor's degree means a person can communicate, such as write emails with the appropriate levels of specificity.
- A master's degree means a person can perform a profession with advanced critical and/or original reasoning.
- A doctoral degree means a person can conduct research.
From the most generalized of considerations that's it. Education means nothing more than those few things, but those few things are exceedingly important to certain careers.
So, what does that mean for software? In most cases, nothing relevant. In most cases software skills can be self-taught. I am self-taught and can perform software development objectively better than many university educated developers with regards to speed of delivery, originality, and quality/speed of product.
It is necessary to debunk many false assumptions of education. First, education exists as a formal model to expand knowledge with qualified guidance. Second, education is not a license to practice in any profession. For example you need a law license to practice law, but you need a law degree to apply for the licensing process. Education is a prerequisite but the license to practice is the license not the education. Third, education is not directly an indicator of performance or potential in any regard, but is indirectly strongly correlated with both performance and potential. Forth, education is frequently used to determine professional compatibility, such that people with similar educations will write software in similar ways. That is true, but it's also both extremely good and bad, because it's a monocultural where all benefits and consequences are greatly multiplied at considerable risk.
Monoculture aside, a bachelors degree in computer science is little more than worthless. It costs a tremendous amount of money for an insufficient increase of value. My recommendation to get the most of your money is to get a communications degree and teach yourself programming.
Graduate degrees, on the other hand, are extremely valuable to computer science. Graduate degrees, masters and doctorate, provide a substantially better education than what you can provide to yourself. Graduate degrees also increase your earning potential and probability of promotion in the corporate world.
Performance evaluation requires measures. Software execution performance requires measuring execution time against a clock and comparing that clock time to the clock time derived from an alternate approach. If a developer does not do this they are guessing.
The problem with guessing at execution performance is that such guesses are wrong about 80% of the time. Of those wrong guesses more than half, perhaps 50% of all guesses, are catastrophically wrong by several orders of magnitude. That shouldn't be a surprise. People most typically guess out of convenience for self-serving validations, which can't be trusted. Worse, there is no way to know how bad a guess actually is unless it is measured. So, if you want to know what is actually happening there are 3 possibilities:
- Measure the various approaches up front and proceed in an evidence-based manner.
- Guess, and measure the guess later to see how wrong it is.
- Never measure and be blissfully ignorant about how slow things perform and how wrong you are.
Since execution performance, when done properly, requires evidence from clock times it is strenuously objective. Such objectivity is the most useful means to determine the character of a developer. A developer must either accept, discard, or ignore evidence presented to them. The motivations for any such decision can indicate a developer's thinking when presented with a challenge.
For example, is the developer discarding the evidence because it destroys or invalidates positions they require to perform work? If a developer is provided evidence that querySelectors are, at best, 400x slower than other means of DOM access they may discard such evidence if they cannot do their jobs without querySelectors. That is a form of integrity violation, which could indicate narcissism but more likely demonstrates a lesser self-serving bias of face-saving behaviors in the context of gross incompatibility.
I wrote a bit about Ethics. Ethics is a thoroughly studied and well known phenomenon, just not in software. In practice is so well known that it in other industries it is codified into a series of agreed upon rule the violation of which will end your career forever. In software the very idea of ethics is absolutely foreign.
As an example of just how foreign ethics are to software the following thought is commonly uttered by many developers: "My first priority is to put the interest of my users first." In theory that sounds ethical, but in practice it isn't achievable. When you challenge this asserting with evidence the rebuttal is most frequently some form of narcissism thereby indicating the motive behind the term is inherently a self-serving platitude. Self-serving motivations at cost to the primary consumer of a good or service is the opposite of ethics.
For example, if a developer uses query selectors to access a page and they are provided evidence demonstrating query selectors are 400x slower than other means of access they have to make a decision. In order to put the user first they have to discard query selectors so that the application executes faster for the end user. For many developers this simply isn't possible, because they lack the capability to understand the alternate conventions. At that point they are claiming to put the user first when they know, with evidence, they are not. That is deception, a lie.
Deception is a demonstration of narcissism whereby a person is using false statements to make themselves feel important and then using this newly formulated pseudo-confidence to convince others of the same. When deceptions are reinforced and tolerated by an employer toxicity follows. Even though the immediate impact of these tiny deceptions is a minor tarnish of product quality the problem is the behavior and human behavior is not so narrowly confined. Toxic behavior will manifest and grow in a variety of concerns far outside product. In practice such toxic behavior is allowed to occur, because the controls necessary to eliminate such are poorly understand and not worth the investment if developers are frequently perceived as a disposable cost center. To lower risk to the business of larger employers the behavior is frequently isolated through the use of complex tools, excess processes, and division of labor separate from revenue generation aspects of the business.
Since in software ethics are foreign there is no reason not to behave in this manner as a developer. This behavior absolutely tarnishes the quality of product and increases risk in a definite measurable way, but it increases the perceived value of the developer in a narrowly limited social context, which is necessary for career advancement in the absence of other measures. As a result ethical violations are frequently rewarded and reinforced by the harmed business.
The best way to combat ethical violations is to always lean into objectivity in a deliberate and forceful way. Objectivity, with evidence, is necessary because it does not allow improper social validations as qualifiers for product validation. Objectivity is accomplished through the use of measures and automated controls. Measures provided uniform evidence of quality in various different ways and automated controls ensure that quality targets are applied equally without bias.
From a leadership perspective transform the thinking from qualitative asserts of importance to quantitative goals of product. Instead of claiming some easily abused gibberish like "My first priority is to put the interest of my users first." instead claim something specific and measurable like "My pages will load in less than half a second." A quantitative goal forces some level of quality compliance as opposed to vague qualitative statements that reinforce deceptive behavior.