Sigh. I’m at the point where I could honestly care less what language/library someone knows. I’ve been working through a big pile/mess that a recently departed teammate has left me to clean up. I wish I had had more bandwidth to see what was going on.
What I wish I could figure how to reliably measure when we get around to hiring a replacement:
- do they care? They don’t have to agree with my opinions. We can hammer out a compromise with enough laughs. I just want them to care. Because there’s still a lot of things that even the best protocols, procedures, and practices can’t cover.
- can they be responsible? Or have they bought into the fantasy where they offload responsibility to a “decider” while they play the role exclusively of “doer”?
- can they and will they ask questions?? To customers, to teammates, in online forums, wherever. Or does their insecure ego prevent them from feeling the fool so that they can become the wiser?
-can they be critically honest? Admit what they don’t know when debugging, avoid conclusion jumping, candidly self asses? Or do they need some form of myopia to maintain a narrative about their abilities, their contribution, their value, or the environment around them?
If I could reliably convince myself that someone scored strong in these four areas, and had rudimentary programming aptitude we could just skip the rest of these “hiring/new employee” diatribes.
A unexperienced person that cares and has the ability to learn is always better than an experienced guru who does not care and has no grain of professionalism inside them.
For me people that don't take responsibility like that ultimately have an issue with themselves: Yeah they might be wasting my time — but more than that they are wasting their own time. If they are as good as they believe they are, why do they end up in a job where they don't care? Not caring is okay, but where is the ethos of the craft? I might not care about the particular problem of a customer, but I might care about the reliability, quality, extendability, readability and performance of the code I wrote.
Caring costs energy, sure. But not caring can cost you even more, as you are wasting your life.
> I might care about the reliability, quality, extendability, readability and performance of the code I wrote.
This is a brilliant definition of professional ethos.
A further poster asks if companies pay for this. I understand that "do I get paid for it" is the question of the age, but I see that as a reflection of one of the evils of the age (every age has evils and goods).
The money you get paid is a means to an end, not an end. I feel better about myself knowing I have lived up to my standard, money cannot compensate for that.
Money gets you the respect of people who don't know you. Professionalism gets you the respect of the people who do, including the person who knows you best, yourself.
> I feel better about myself knowing I have lived up to my standard, money cannot compensate for that. Money gets you the respect of people who don't know you.
This only applies once you make enough money to be comfortable. Before that point, money directly correlates to quality of living.
Have you considered that this is just you fully internalizing capitalist/protestant propaganda? I'm asking because I agree with you and feel the same way and worried I've just learned to love big brother
I also feel the same way and believe that this is not due to internalising capitalist propaganda.
Caring about quality is above capitalism or communism. Yes, it can be exploited by any political regime and it is necessary to be aware of this exploitation, but regardless of what is the environment I feel proud of doing a great work.
I think it is because we are naturally attracted to beauty and repulsed by ugliness.
Not the parent, but of course this is something to be considered. But for me the will to deliver professional level code exists despite capitalism, not because it. Good designs, fitting elegant solutions that have positive impact on the people who have to use them are not capitalist. What is capitalist is people just churning out code without considering whether that code is reliable, makes the world a better place etc. Thinking about code quality this way is anti-capitalist, because you say: There are things that matter more than monetary capital or short term gain
There is little demand for those craftsmen that care. Company owners want their employees to be passionate about their jobs, but do they want to pay extra for the craft? No. Artists are poor in our society for a reason.
I think most companies are extremely dysfunctional with unhealthy attitudes towards their workers, but if there's one thing they do for programmers, it's pay. Even in Europe where we don't have FAANG salaries programmers are among the highest-paid craftspeople.
If you’re at a company where things are bad and you have limited ability to improve them and can’t just quit then caring about what you do just makes it all the more upsetting and difficult compared to switching off. Recovering from this and going back to being optimistic and caring is difficult.
Do you mean really care or just be good at pretending? The first thing I learned when I started working is the importance of not caring.
Caring can cause innner-team conflicts and burn out. Yes, you need to appear motivated but caring too much will just make you annoying.
Also this is more about the power of influence I get over a project. If I get real ownership and the power and tools to make decisions, yeah I am going to care, if not, not, just no. I am not wasting mental energy on things I can't change.
I will pretend to care about anything you want me to care though, if the pay is right.
Honest question: Are there things privately you care about? I take pride in parts of my work with the same emotional response as I take pride in my family. Not exactly the same magnitude, but the same emotional pathways at work. After 15 years of working I've learned to say "no", manage emotions, etc. to become at least robust in not 'caring' about office politics and such (in the emotional sense). But I do care about my work. It's the main thing I do.
Sure, there is lot's of things I care about privately. In fact I absolutely love programming languages and it took me a while to separate my excitement from my professional work.
Your family comparison is super weird. There is no love and loyalty between employer and employee. The relationship is antagonistic by nature. If I find a better job, I am out. If they don't need me, they will kick me out. They pay me the minimum amount they can get away with and try to squeeze out the maximum value. They don't care about me as a human being and they should not, that is business. (It is the job of labor laws and unions to make the interaction more humane, I don't believe in idealism.)
Of course, I still have professional pride and given the choice will try to do a good job but for me being a professional also means being emotionally detached from it. It is just business. I work for money. The meaningful stuff in my life happens outside of my employment.
"Super weird" /to you/? I just ment to underline that (for me) it's the same type of caring. I'm professional, could do the same job at a dozen employers, etc. I think we feel the same about that.
But I care about my work in a deep way that you don't seem to feel. If I manage to get a junior / medior to properly step up to a task and grow confident I feel pride, connection and sense of doing the right thing. The whole business layer comes second for me at that moment.
Another thought is that I feel that 'in Europe' (generalisation) the antagonistic nature of employment is not felt the same way especially for professional jobs. We have no firing at will. As an manager I understand that I have a multi year relationship with people that should transcend the tasks at hand. The tasks at hand should be done and done well, but a job should be both fulfilling and manageable for the individual. Even if a hiring fails somewhat you have to make it work. The current job market creates an even bigger reason to treat people well.
Are you saying people in Europe care more about their jobs?
That's certainly not my experience. I've met just as many Europeans that hate their jobs and just do it for the money. They spend as little time as possible doing them.
Well, if a given architecture doesn't allow for another solution, that might be the only implementable choice.
Remaking the core architecture to solve an obscure bug which only happens when you've got overlapping leap years and leap seconds is most certainly a bad decision.
For a simple example: Phillips hue movement detectors don't work for a very short time before new years. (My guess is that they're validating the year for the activation signal). I don't know how the bug occurs, but i can imagine several ways in which this could become unfixable if a given architecture was chosen... I still want it to work though, so I'd really like it if they'd just added something like your example.
I think it's more likely you just haven't been in a company with coworkers who write this kind of code chronically, and also opt out of any participation in architecture meetings or design reviews. Just interminable finger-pointing and stop energy any time there's some critique.
How about these implementable choices for a dirty fix:
- make lightbulbs work in these last seconds of the year 2022 and only that year
- make lightbulbs work in the last seconds of years 2023-2036 or more
This is the distinction I've been trying to make: there are sometimes powerful incentives pushing workers into the former, even if the latter could be approximately the same effort.
I was thinking more about solving it at the source vs essentially just catching the error case and overwriting the behavior.
And while the latter is definitely "code smell"/technical debt... Sometimes, there aren't really any good solutions to a given problem
There is much truth in this comment, many people don't wish to see this and are there suprised when their "nice boss or management" fires them without caring how they will support their family.
Yeah I always struggle with the “you just need to care less, you’ll be happier that way” theme.
I spend 8-10 hours on a given day exchanging my work for some revenue. That is (at least) half of my waking day. Day after day. To the tune of ~2000 hours a year. That is a massive part of one’s _life_. I think it’s reasonable to want some sort of satisfaction during at least some of those hours.
Also, I find it takes active effort to actually not care. It is not a minimum energy test state for me. I actually have to work even harder to do the job and NOT care.
If you are a programmer who doesn't care about your user, you are a terrible programmer - period.
Care about the user, programmers. Not the manager, not your fellow work competitors. The USER.
Without a USER, nothing you do has value - at all.
(Note: your manager and your fellow work competitors can be users too. Don't overlook that fact! Hopefully they care enough about the users, too, that they are willing to wear the user hat during your product development cycle. Even managers wearing users hats are users. I hope you still care even then!)
You are right in the sense that thinking from the perspective of the user is a good professional skill to have.
In practice though, you a very privileged if you get to work on any software that is not user-hostile per design. In the end of the day, programmer don't make the decisions.
If you care about the user but management prevents you from acting on it, you are hurting yourself for no reason, like agonizing over all the bad news across the nation and world. Your shoulders can't carry the whole world
You are describing not a problem with caring, but a problem with bad leadership that destroys the benefits of caring and the people who care.
Stopping caring is a coping strategy to help you extract funds (if you aren't getting good funds, leave!) from a company that refuses to let you do good work.
> Sigh. I’m at the point where I could honestly care less what language/library someone knows.
I totally agree, but with the one exception - C++. The language (and its ecosystem) is so complex that I don't see someone without experience being able to be a lead developer of a large C++ project or to be able debug non-trivial bugs in C++ code. Debugging is one of my strongest skills, I can debug code written in many languages including C but when it comes to C++ I often helpless. I don't see myself being confident in C++ without spending years to master the language.
For individuals to care, the institution (represented by leadership) needs to care too. Does it?
The decades of neoliberal dogma ingrained into management that everything should be done as cheaply as possible, and nothing else matters. To me, that is a very definition of organisational not-caring.
MBAs, in principle, cannot build a beautiful cathedral. That is lavish for its own reasons. If everybody chases money, nobody chases anything, really.
That's simply not true, you can care about your own work standards and professionalism even when others don't care about theirs. "They did it first" isn't an attractive excuse, even if they did.
You can, but then you risk burnout. We are social animals, we not only want to do the right thing, but the right thing also has to be supported by others. If it is not supported, most people will just give up.
> - do they care? They don’t have to agree with my opinions. We can hammer out a compromise with enough laughs. I just want them to care. Because there’s still a lot of things that even the best protocols, procedures, and practices can’t cover.
Are their pay and their working conditions the best that the market can offer to them?
> - can they be responsible? Or have they bought into the fantasy where they offload responsibility to a “decider” while they play the role exclusively of “doer”?
Do they have the decision power and the salary that go hand in hand with high responsibility?
I would argue that you have presented a chicken and egg problem.
As a business owner I am reluctant to offer a new entrant the best pay “that the market can offer”. Working conditions - a company can only offer the best within their means.
I know that good faith must comes from both sides, and a company has to offer something worthwile in return. Like any type of relationship, its a two way street.
But a sense of entitlement firstly, and then maybe if the company is lucky that the employee will care and take responsibility - that is a relationship one better not enter from the onset, if it can be detected ahead of time. Its just the wrong value set.
I would also add that a company that displays the same kind of entitlement towards its workers, is also not worth an employee’s further attention.
So do you regularly increase employee salaries to match their demonstrated competency and responsibility? Or are you like most employers, giving new hires better pay than your current top performers, incentivising your top performers to find a better paid job somewhere else?
tbh it's blurry in English too, because you can be abstractly "responsible" / "a responsible person" which is a general virtue, while also being "responsible for" something / "the responsible person" i.e. some formal role which should also come with compensation. But I think the former case is what travisgriggs meant, and it's also something I expect from everyone regardless of level/role/pay.
If someone's answer to "why does clicking 'Save' and then reloading not show the saved data?" is "the product requirements only said there should be a Save button, not that the data should be saved", I don't want to work with them. If you want something like this go work for a body shop, not a product-focused company - and then don't complain when you never get the interesting technical work.
I agree that everyone should feel responsible for fulfilling their part of the contract, not just in the most shallow way.
> "the product requirements only said there should be a Save button, not that the data should be saved"
If these were really the requirements, then the PO's salary should be split and go to the developers, because they would need to do that job anyway and at least do not get distracted by an incompetent PO.
You think a PO is incompetent if they hand over a mockup with a "Save" button and not a 200 page document that among every other detail says "Clicking or otherwise depressing the 'Save' button should persist the information in fields A, B, and C into the database within 500ms" or some such overspecification? We're selling ads, not sending people to the moon.
This kind of culture eventually produces the equivalent stupid formalization on the dev side like "all modules must have at least 99.85% coverage and a three-phase UML diagram review by the architecture team before deployment".
Better to have some slack and people willing to use common sense on both sides.
I think a PO is mostly useless if they do not provide a clear set of acceptance criteria. Low-effort requirement descriptions are just shifting the responsibility to the developers, because they leave too much room for interpretation. Lack of technical understanding is another common source of friction. TBH, the best PO that I worked with has a CS degree.
I agree. I'd expect a huge compensation gap between someone who types up "make a save button" when the user says "I want to save", and some who comes up with "Users wish to persist state between uses of the application, therefore we want to retain the users current balance, brightness setting..."
The former shouldn't be paid more than a front desk receptionist, and I'll keep the difference since I'll be picking up the rest of the role.
I did say "a mockup with a Save button", not "a rock with 'Save plz' carved into it thrown through the devs' office window." Yes, the PO has to care too.
I guess count yourselves lucky you've only had bad POs and not bad POs and bad developers.
I think we are talking about different complexities of projects. In a complex project in a complex environment in a team larger than 2, a mockup often does not cut it. I've seen underspecified requirements leading to misunderstandings countless times. I have never seen a situation where I thought that writing down those 5-15 acceptance criteria upfront was a waste of time. The discussions that follow when a deadline was missed because of misunderstandings feel much more like a waste of time to me.
In a simple project a mockup can be enough, but then what do you need a PO for?
Mockup is great if you are just working on the front end, but what is the save button actually supposed to do? I can figure that out, talk to the users and understand what they want to save, but I feel like that's the product owners job.
Likewise, a programmer who can only code a solution when given a spec like the latter, should only be paid as much as the help desk tech, since the PO will be picking up the rest of the role.
I can get a receptionist to type "make a save button" into a jira ticket when the customer asks for it (that's more than some PO's I've had have done, some would just copy and paste the email from the customer into the ticket providing no additional context or clarification), can you get a help desk person to build the app?
The absolute worst PO I ever worked with had a CS degree, and kept asking stuff like "why aren't you using MVC" and specifying technical details that wouldn't work rather than a product vision.
Deep technical knowledge can help a PO, especially in technical products, but it should not be influencing how they present to the dev team. Otherwise they're just another even-less-accountable architecture astronaut.
> I’ve been working through a big pile/mess that a recently departed teammate has left me to clean up.
I’ve heard some version of this statement for years.
I feel that it is an almost guaranteed result of today’s “mayfly tenure” pattern. With the entire industry and engineering career structure, based around (and rewarding) tenures of two years or less, there’s almost no incentive for engineers to leave a legacy.
Instead, “quick fixes,” and “buzzword bingo” work is rewarded.
Who cares if it goes pear-shaped when the next OS comes out? I won’t be around to clean up the mess.
I’ve spent my career, maintaining my own code, and have learned to leave a legacy[0].
I was just working yesterday, on a new fix release, of an app that has a provenance that goes back ten years (Through two different codebase pivots)[1]. I walk through its history, in this comment[2].
I’ve learned that it’s not a good idea (for me, at least), to be saying “you guys are doing it wrong, and here’s what’s wrong with your approach.” That type of thing tends to get lots of clicks and upvotes. Internet rants go viral, hereabouts, on a regular basis.
Instead, I have learned to say “This is my approach, with the results, and here’s links to the proofs, in my own work.”
When I make general statements, I tend to qualify them with “I feel as if…”, or “It is my opinion that…”, or “In my experience…”, etc.
As you have demonstrated, it often results in downvotes (I suppose, because it is perceived as “arrogance”), but I won’t engage in poo-throwing.
The Internet is already bad enough, without my contribution. In The Days of Yore, I was a highly effective troll, and I have some atonement to perform.
Actually, it doesn't. I'm pretty sure HN links are nofollow. I don't care. I don't do it for SEO, and I'm not looking for work.
I have been linking to my work for as long as I've been posting, here, and will continue to do so, for as long as I participate.
You will also note that I am not anonymous. I make it very easy to find out who I am. You could probably easily find my home address and phone number, from what I post.
Helps me to be accountable for what I write. I spent my entire career, being highly accountable. I feel that it helps me to build my character.
I don't care whether or not I'm some kind of "Internet essay star" (Spoiler alert: I'm not). I write what I write, for my own good, and so that anyone that is interested in finding out more about me, can do so.
I've been at this stuff for a long time. I also spent almost 27 years at one of the most anal corporations on Earth, so my work has a lot of polish. It has nothing to do with trying to be "better than" anyone else. It's just the way I am. I feel it's pretty good.
I've certainly encountered worse. When I do, I take it as a lesson, and don't get too bogged down in nursing a grudge. I also regularly encounter better, and I like to take that as inspiration.
Additionally, 27 years at a Japanese corporation taught me to back up what I say. If I say "I do this," then I'd damn well better be able to prove it; which is a big reason that I keep linking to my work. One advantage of being old in the game, is that I have a lot of track record that I can reference.
I like working with people. I always have. I'm a decent chap. I want to be a contributor to the world. I know that writing positive, contributory stuff is a bit quixotic, but, that's me; tilting at windmills. I won't add to the negativity; even if I can't singlehandedly make things more positive.
I'm retired. I have no interest, whatsoever in ever working for anyone again. I'm not interested in selling a brand. I work for free, for folks that can't afford the kind of talent I have. Whether or not some random, anonymous Internet dude loves me, is of little concern.
Listen, this is the second time (that I know of) that you've insulted me, and I don't remember ever attacking you (or anyone else, here, for that matter) out of the blue.
Would you like to try resetting the relationship? You'll find that I'm actually a kind, generous person, with a very positive outlook on life, and a true desire to Bring Light.
I'm really, really good at some stuff, and really, really bad, at other stuff. I don't hide either.
As an employee, I don't know why I would want to be any of those things, as I am just going to jump to another company the next year as I did not get a raise.
This career is mostly leetcode with a year of cooldown time doing enough passable work to not get terminated. I completely get why employees do not care and are happy to let bad decisions by others go unchallenged.
There is a bug at my job that is costing my company several hundred a day. I could fix it or I could just ignore it and avoid having to write a ticket, deal with feedback, and generally having to speak.
I think the responses are telling, nobody presenting any convincing arguments. For some reason nerds are very unwilling to acknowledge status, power politics, wealth disparity. Maybe they're just all temporarily embarrassed unicorn startup billionaires?
> I am just going to jump to another company the next year as I did not get a raise.
Why would anyone give you a raise if you work with this mindset? People get raises and promotions. If you don't, the responsibility for such situation is very likely at your side.
A raise is not a reward. It is the baseline expectation in a high demand industry.
I can get the raise/promotion for doing little besides interview prep. If you cannot beat the effort to raise ratio, the optimal strategy for me is to do a mediocre job.
What I find fulfilling doesn't pay anywhere near as much as corporate SaaS. I am sure some are passionate about corporate digital security, but very few.
Does the company praise programmer A whose programs run without error, or programmer B whose code crashes in production at night, but the 'hero' (B) is coming in at midnight and fixes it?
A lot of management will praise B (good job, you saved our a..); creating a very very wrong perception.
For ANY JOB this is ALL that matters. Languages/Tools/Frameworks etc. can all be learned as needed. But if you don't have the above character traits nothing can be done. This is also known as having a good attitude. Companies abysmally fail at identifying and nurturing these traits. They go after the secondary noise (easily measured irrelevant parameters) rather than the primary signal (nebulous and hard to measure).
I believe every HR department should be staffed/supported by psychologists from CBT and ABA domains to really nurture their people.
In interviews I usually just ask developers to show me some code (any code) and ask them random questions about it. I’ll ask them what libraries they use and why, or why they wrote some piece of code the way it is, or why did they or didn’t test certain pieces of code.
Their answer will usually show their (reasoning) skill and whether they care. Talking and reasoning about code is an important skill for a developer for me, so that’s what I’ll focus the interview on.
I don’t care whether the library is a good or bad choice. I don’t care about the code itself or whether it’s good or bad. I just want to know if they can tell me why it is the way it is.
> can they be responsible? Or have they bought into the fantasy where they offload responsibility to a “decider” while they play the role exclusively of “doer”?
I do want to care but decisions feel remote even when you ask or provide feedback and it's overlooked only for it to come back later that what you had suggested was plausible and is being done only a few months late when you've already implemented an RMQ integration that was possibly avoidable.
It's demoralizing when your company starts moving in the direction of bug resolution is simple of a legacy system whose original authors are no longer with the company and you need to be pushing out 10 JIRA tickets in two weeks. Clearly trying to turn the engineers into code monkeys how am I supposed to care in this environment?
> If I could reliably convince myself that someone scored strong in these four areas, and had rudimentary programming aptitude we could just skip the rest of these “hiring/new employee” diatribes.
The best way I've found to identify these people is to look for people in existing jobs which require such skills, who now want to move into development. That can be any field where there's similar personal demands to achieve a high level of skill, whether that's technical-related (civil engineer) or not (cook, musician, sport).
These people are also often overlooked by traditional hiring processes so if you can get a process in place to find them, it's a huge competitive advantage when you can't offer FAANG salaries or on-site barbers.
I think this is the main property of seniority, with seniority comes a bit of self-assurance and not really caring if someone thinks you're a fool for not knowing what X is when you know what A - W is.
If I could add one bullet point to that list it would be:
- do they document their thought process behind non-obvious choices in comments?
My code is usually peppered with links to SO, explanations of why I'm doing this or that. You never know, the next maintenance programmer to touch that code might be me. I'd like to know what I was thinking when putting that heap together.
What's very funny to me, is that I can easily imagine every person I've ever worked with writing this same list, and also thinking of themselves as ranking highly. In fact, I think this list mostly boils down to "Do I like this person?". But that might be the most important question of all.
For me, that's number one. Often, really smart programmers are really terrible at communicating about what they're working on. They get into Lone Ranger cowboy mode and write tons of code without telling anyone what they're doing. They may get a lot done on their own, but it makes them nearly impossible to work with as colleagues. If I had to choose between a coworker who wasn't very good at coding and a coworker who wasn't very good at communicating, I'd gladly choose the one who isn't very good at coding.
I'm sympathetic to this perspective, but the other side of this is that the most enjoyable time in my job is headphones on listening to music in a flow state. I've been accused of being a lone wolf on projects. It comes from the selfish place that it's simply more enjoyable. Architecture conversations and code reviews can be fun, but collaborating on a project I could do myself (and especially pairing) often makes my job less enjoyable.
can they be responsible? Or have they bought into the fantasy where they offload responsibility to a “decider” while they play the role exclusively of “doer”?
You just scratched my itch with it.
If you are responsible, but nobody cares to fill you up on project details and latest decisions and news, you can’t make your own decisions, because decisions have to be made in line with something, not in a vacuum. They come naturally if you are aware of the situation, and do not if you aren’t. Constant info starvation leads to this behavior even in those who are fully responsible and autonomous otherwise.
Our management does that a lot. They [re]decide or [re]plan something, sprinkle few-worded contradicting tasks around, as if everyone was in course, and then get too busy to answer. So the whole day turns into an investigation because nobody can decide nothing. This “effective” management saves minutes of explanation for days of doing complete garbage and then brags on what an “effective” team we are at corporate events, while literally everybody sits smiling out of subordination having no clue what the fuck they are babbling about. (It’s not just my guess, I’ve talked to them all.)
Not claiming that you’re a boss who demands to run a business for you blindfolded. But since you’re making a list, please make sure you’re talking about truly indecisive guys and not the lack of communication.
This may be a hot take, but if you thing that $programmingLanguage is a discrete skill you're doing something wrong.
That's not to say there's a minimum amount of knowledge to understand about $language (be it memory safety and UB in C/C++, virtualenvs in Python, auditing and setting up dependencies in node, how to set up tsconfig.json, whatever these are random examples). But the core skills of software engineering are not writing code.
I feel there's going to be a point in the next 10-20 years where we establish the difference between programmers and software engineers like there is between mechanical engineers and car mechanics, electricians and EEs, contractors and architects, whatever. The line is super blurry today which is fantastic for labor since we don't have too many hurdles to get into any role, but eventually companies or governments will establish them. I think I'd be happy to be a programmer for my home stuff and hobby projects like people who like to work on their cars, but I also value other domains of expertise like people who design them - and the choice of language is an implementation detail. Over investing in any technology is bad move, when it kneecaps your ability to learn or choose others.
> This may be a hot take, but if you thing that $programmingLanguage is a discrete skill you're doing something wrong.
Hello programmer! I'm a recruiter. It definitely is a distinct skill to know different programming languages. The reason is that years of experience shows that different pain points exist in different languages. What I'm looking for is someone who can anticipate those issues in advance. Moreover, software architecture is different in languages and building for scale as well. These things are honed through experience. So no, people aren't doing something wrong.
Disclaimer: I'm not a recruiter. I'm a programmer, and I don't believe a word I just wrote. I'm fairly sure that some do.
Which is why in some countries Software Engineering is a protected title, with a specific set of skills to assess, and we don't go around calling ourselves "engineers" after a six week bootcamp.
We might still call ourselves engineers without the admission exam (which is a legal gray zone if signing projects), yet the university degree was anyway certified by the organization and the only thing missing is the exam.
As an "engineer" with the corresponding university degree, I am absolutely against software engineering being a protected title, for several reasons:
- We are nowhere close to a set of widely agreed required, specific practices for a software engineering project. "Signing a project" is meaningless without those specific practices.
- Even if we had those practices, this world changes so fast that they would need to be updated frequently and get people to examine themselves again.
- There's no test for the characteristics underlying components being used. If I'm building a bridge, I can specify certain characteristics for the materials and the procedures, those things can be tested during/after construction and if something fails, we can try and check what failed and pinpoint responsibility (was it a bad procedure, a bad implementation or a bad material?). That's utterly impossible with software. A program crashes or has a bug, and whose fault is it? Nobody will be signing any project and assuming the responsibility it comes with when there's no reliable way to pinpoint who's responsible for a failure.
- There isn't even a specific set of skills for an engineer that we all agree on. Yes, you might say "know programming languages" or "testing" or "project management", but what does actually mean? Do you need to know Agile to be a software engineer? Or assembly? Or A/B testing?
And finally and the most important thing for me: the amount of knowledge you get from a degree is just a small, often antiquated, part of what's actually software engineering in practice. As someone with an actual software engineering degree, I do not think that the degree is necessary for someone to be a great software engineer. Most of the important knowledge will be learned on the job and on various Internet resources anyways.
In my opinion, making SWE a protected title will, at best, do nothing. At worst it will put good engineers without a title out of a job, for no actual change in the quality of the software.
High integrity computing has proven record of what those practices should be.
As for the rest of your arguments, let me rephrase it,
And finally and the most important thing for me: the amount of knowledge you get from a degree is just a small, often antiquated, part of what's actually medicine in practice. As someone with an actual medicine degree, I do not think that the degree is necessary for someone to be a great doctor. Most of the important knowledge will be learned on internships and on various yearly conferences anyways.
In my opinion, making a doctor a protected title will, at best, do nothing. At worst it will put good doctors without a title out of a job, for no actual change in the quality of the treatments being applied.
> High integrity computing has proven record of what those practices should be.
And high integrity computing is applied only on certain projects with limited scope because outside of that it's not viable. I'd like to see high integrity computing applied to a web app.
> As for the rest of your arguments, let me rephrase it,
You might rephrase it as much as you want, it does not make it an apt comparison nor an actual argument. Funnily enough, my SO is a doctor so I see how different our education and work is.
The set of base knowledge they get in the degree is not small nor antiquated: there's nobody releasing a new human body every other year, but in SWE we have new operating systems and new execution environments constantly. The set of tools doctors use is fairly constant and consistent between hospitals, in SWE two companies might have entirely different processes, tools and code, and still be functional.
And while yes, doctors need to learn new things constantly and there's quite a lot to learn on internships (which, by the way, are different from SWE internships, as internships in medicine is where doctors get their specialization education), from what I've seen I guarantee you there's practically no way one could be a good doctor without having most of the knowledge they learn in the degree and the specialization years.
High integrity computing is still not widespread enough, because unfortunely lawsuits and liability procedures aren't yet common, but they eventually will.
We only need a few more media star exploits landing across social media for goverments to finally act upon it.
That web app would have a process just like anything else.
It would be more expensive?
Certainly, yet the food joint down the corner also needs to oblige to safety regulations if it doesn't want to be closed down by health inspection, and yet they manage.
Hospitals have workflow and treatment guidelines for a reason, they aren't the same process in every single one, not even on the same region on the same country.
It is clear which side of the line each one of us is, so not worthile to discuss this any further.
Most business software isn't safety critical in any way. If you're arguing that we need a framework around things like "self driving" cars, then sure. There are already processes for software in medical devices.
I'm personally eating a steak from a restaurant that isn't inspected, the risk is low and any restaurant I'd go to for a steak relies on repeat customers. The incentives are aligned. Inspecting ground beef at the source makes sense, but that's a different matter.
Sometimes cheap has a quality all its own, to paraphrase and repurpose Napoleon.
For the same reason in any other kind of industry, when things don't work they get refunded, and when things go wrong people get sued.
Software shouldn't be a special snowflake in that regard, and because it currently is, that is what allows business to disregad quality and good software development practices.
Even 1 euro shops and street food joints have a minimal set of quality standards they must adhere to, or get closed down when not.
The US doesn't have "engineer" as a protected title (*) and I think that's a good thing. We shouldn't gatekeep behind expensive and time consuming doors.
(*) except for PEs, which except for a handful of industries no one really cares about
5 years learning about various programming languages, OS architecture, distributed systems, graphics programming, algorithms and data structures, soft skills like project management and risk assessment, physics, math, electronic and digital circuits, among others.
software engineering is definitely different than programming. i didnt understand this until i moved up from an iddy bitty company to a big one. fortunately i learned the rest of the skills on the job but it was a bit of an adjustment for me
I definitely don't think so, but a lot of hiring managers and recruiters seem awfully convinced of the opposite. Despite all of them using the exact same concepts.
I do the opposite. Across C, Python and Go, I was prepared and had a good understanding of the languages and stdlibs before joining through reading books and working through the exercises.
It worked very well for me, on joining my knowledge of the languages and their stdlibs was respectable, and I could hit the ground running and get patches accepted easily. I could also in each languages case fix weirdness they had in their code because their own knowledge had gaps. That impressed people and made a pretty good first impression.
It's probably not universally true, but in my observation learning on the job much more commonly ends up resulting in sizable gaps in language knowledge.
If you've got a role working in $LANG, I don't see how upskilling in $LANG before you join is a trap. It's commonly knowledge with lasting value that offers returns across jobs.
I've never worked with C++, I hear hints that it's too big to actually learn and instead one must learn a subset. Maybe that's true, and the article more applies there.
Agreed. Personally I'm always grateful when someone joins and brings along a good up-to-date idea of how our particular languages/frameworks are used and taught by the rest of the world. It's so easy for a big internal codebase to devolve over time into a bunch of weird patterns, and forcing some newcomer/outsider perspectives onto it is a great corrective force.
Of course learn the language you're going to use. But you can't expect to make do with just one.
In any case you'll face SQL; learn it. It's a language on its own, with interesting and non-intuitive concepts, a number of features, and great power.
Learn bash, because you'll have to talk to the OS somehow! (Yes, even macOS. But you don't normally deploy to macOS only.)
Learn some HTML and CSS, even if you're a backend developer, enough to show a simple status page for your service.
Read an intro into YAML, it's not that trivial! It's useful around great many modern tools. TOML is good to know, too.
These are all proper languages, worth knowing for a long time and learning. One could also say that Vi's system of commands is also a language, because it has syntax and is composable; worth knowing, too!
This is on top of your language of choice; for backend or mobile development you can usually make do with just one, for web frontend you have to know enough JS, HTML, and CSS at the least, TS is a really good idea, too.
Depending on what kind of work you do, it can also be helpful to learn at least the basics of various "back end" (or "system") languages and libraries out there.
For example, one of the following in each categories:
- something for number crunching and statistics: Python or R (went with Python here, also has nice image/audio processing libraries)
- one of the more popular higher abstraction level languages: Node, Python, .NET, Java, PHP, Ruby or another one
- perhaps something for being able to create static executables and packaged tools/utilities: Go, C/C++, Rust
- maybe something for GUI tools (opinions vary, I still like Lazarus/Pascal, most might go for Electron, others grokk Qt/GTK etc.)
Chances are, you won't need all of those in your day job for the most part... until one day suddenly a use case will present itself, where doing it in one of those languages will be easier than whatever you're using already.
Plus, it can make for a fun few weekends, if you have the curiosity and time to spare. If you can get your company to pay for you upskilling yourself and don't have to fall into the "1 year of experience, X times" trap by just fixing bugs, even better! Even better if you learn multiple of these and then can reason about which tool might be better for any given job.
My job/team might be the exception to the rule, but anyways:
"In any case you'll face SQL" -- there is no trace of SQL in our project. We're using a NoSQL database. This may change in the future, though.
"Learn bash, because you'll have to talk to the OS somehow" -- our language to talk to the OS is standard libraries. We do have a few bash snippets to glue together the build process, but they are vanishing more quickly than they appear because everybody in the team thinks that bash is inferior to typescript.
You're right about HTML+CSS, and this is a trend I've seen everywhere (replacing UIs with browser-based UIs).
YAML only exists in a single configuration file, and only because the tool forces us to, as well as a second rather obscure configuration file in a sub-part of the project because another tool forces us to. The tools suck hard, they report errors in the whole file even if it is totally correct.
Nobody is using vi, everybody is using either WebStorm or VS Code.
But I agree, programming is wider than this, and you may never face SQL e.g. if you do deep embedded development, but then an ability to read VHDL can be handy, or if you do game dev 3D graphics, but then you'll have to learn the shader languages, etc.
So the question from the survey was:
"Which development environments did you use regularly over the past year, and which do you want to work with over the next year? Please check all that apply. "
So respondents could check multiple. I would definitely check Vim, because I use it often, but I'm not using it as my primary text editor/IDE, but that would count towards Vim anyways - as I understand the survey. From my own experience, most developers use some kind of IDE, but that may be a Danish quirk. Most people still joke about not being able to exit Vim.
Exactly, I think most people use vim when doing stuff on the command line. It's easier to open a config file in vim and make a change when you're poking around than it is to load it in VS code.
> everybody in the team thinks that bash is inferior to typescript.
Let's hope not for the sake of the team. TypeScript is great but it's not Bash. How much time and TypeScript code do you need to read, filter and write content from a text file? More than one line probably.
I have yet to see a language that matches Bash at what it does best. It's one of the biggest time-savers for me.
Lines of code are irrelevant compared to readability, and the latter is where bash loses hard. Time to write and maintain these scripts is far less with typescript.
The remainder of your arguments seems to be based on wrong assumptions about what our build scripts are doing. "Filtering text files" doesn't happen there.
OTOH, in typescript I can include a library for the deployment on various GCP cloud services in a single line in package.json -- how many lines is that in bash? (edit: the sarcasm might not be obvious. Nobody I have ever met knows about a GCP deployment library for bash, nor about an NPM-like platform for bash snippets. Installing command line tools via the platform's package manager doesn't work in practice for various reasons.)
>Lines of code are irrelevant compared to readability
They aren't irrelevant. LoC has influence on readability. Try reading a terse book versus a more condensed book if you don't agree. It's neither as easy as "make it as short as possible" nor "just write as elaborate as possible".
Knowing Bash is about more than just writing build scripts. I use it every day for one-off tasks and trying to use anything else instead would be a huge waste of time.
> GCP cloud services in a single line in package.json -- how many lines is that in bash?
My whole point was: use the right tool for the job. Sure nobody would do GCP stuff in Bash, just like it would be ludicrous to do certain tasks in TypeScript instead. The original statement was about Bash being a useful skill, and imho that's practically undeniable.
> Installing command line tools via the platform's package manager doesn't work in practice for various reasons
I wish installing dependencies via package.json and npm was as reliable, it would save me quite some time.
I'd like to somehow generalize this advice. My take is to compare proactive vs reactive learning.
Early in my career I was all proactive learning. I would study languages, frameworks, tools, anything under the sun. Vast majority of these I never used or got any value out of.
As I became older and had less time in my hands I had to become more tactical with my learning. I started to switch from proactive to reactive learning. Reactive learning is learning new things in response to on-the-job needs. Does my new team use Spark in Scala? Let's learn about those then.
I still like to keep a thread of proactive learning where I do more exploration, just to expand my horizons and have some fun. Still I'd say nowadays my ratio of proactive vs reactive learning must be around 20/80%.
One needs the other, though. Quite probable is that you are good at reactive learning, because of the basis you lay down in your time of proactive learning.
I mostly disagree with this blog post. I think one of the most important things to do, if you're starting a job at a company that uses a language you don't have experience in, is to ask the hiring manager what recommendations they have for learning that language. If possible, ask them to ship you the recommended 1-2 books before you start.
It's true that there's languages so big that any company will use a somewhat-unique subset of the language, but that's not true of all languages. And if it is true, that's why it's important to ask someone at the company for the right resources to learn the right idioms in that language, for that company.
The part I do agree with is that there will be a lot of company-specific stuff like tooling, build process, frameworks, libraries, etc. It's a mistake to think you can "hit the ground running" with a language you haven't used before at a new company, and no amount of studying will change that. All you can do is gain enough familiarity with the language syntax and common idioms that your pattern-matching facilities are already primed, so that when you look at source code you see words and sentences, not characters, if that makes sense. Use the language books as a resource over the first few months as you ramp up on the combination of programming languages, business problems/solutions, infrastructure, build tools, dev tools, etc.
Don't treat pre-start book study as a silver bullet. And if your life circumstances don't give you time to do any pre-start study, don't sweat it; most good employers will give you plenty of leeway to learn on the job as long as you show increasing proficiency over a couple months. But if you have the time, resources, and inclination, absolutely do learn a new language used at a new job prior to your start date.
People might not know what the code base is actually like; they have incentives to overstate its quality; and, even if they can point you to a relevant, authoritative book, that doesn't entail that the hour spent with it is better than an hour spent learning a tool.
I still disagree, but I think I better understand the disagreement now. I find it easiest to learn a new language by starting with the canonical beginner's book, e.g. the Pickaxe book for Ruby. I find it hard to learn tooling like CI/CD, logging/metrics, etc by reading or through personal projects, I much prefer to learn those on-the-job as necessary. It seems like it might be the inverse for you.
Even if a new codebase isn't exactly 'Effective Java' quality, it's good to have that reference to better articulate to yourself exactly how the codebase is flawed.
Not sure what to really take from this article. If it's about what one should spend their time learning, try identify the 'timeless' things. Software design over languages, algorithms over libraries, SQL and JavaScript will probably never die.
Author here. I certainly have a lot of opinions about what to study more generally! This was a short note for people who are specifically trying to make it likelier that they'll succeed at a job they're about to start. Lots of people (former versions of myself included) focus too much on learning a language when studying other tools would give a higher ROI.
It's amazing coming at software from a data perspective, my assumption that people would know about SQL and databases is just so so wrong all of the time.
ORMs definitely don't help! In my first dev role I worked at a C# shop and everything was through Entity Framework. You can't take that skill with you if you change languages to Python, or Haskell, or whatever, but the core SQL skills to follow you around. It's worth the effort, I think (and it's not particularly hard to get semi-decent at SQL!).
In the job market right now, this seems like terrible advice: no one except Google are hiring for "algorithms" - they want a React developer, or a C#/.net developer who can pump out web APIs in it or something.
Companies mostly hire for frameworks below the FAANG level.
Once you get general topics it's fairly trivial to pick up new frameworks/libraries to pump those APIs out. I'm not saying algorithms for the sake of leetcode!
Saying this, I was interviewing for several roles across the US and EU last April and had algorithm-based questions in almost all of them. So it's pretty useful for that reason too, even if I don't really agree with it.
It’s trivial to learn the frameworks needed to be a competent mobile developer? Don’t get me started with the clusterfuck that is the front end ecosystem.
> they want a React developer, or a C#/.net developer who can pump out web APIs in it or something.
All web APIs follow the same basic pattern. The OP said:
>> try identify the 'timeless' things. Software design over languages, algorithms over libraries
If you understand the fundamentals of software engineering, picking up a new framework or library isn't a big deal. It's the same old tropes with some different syntax and domain language. Especially in the world of web development where you're pumping out APIs.
No, Leetcode has metastasized throughout startup land too. I know because I failed a lot of those interview types in the past year (but I keep trying since the pay is so good)
It’s good advice to not only learn about the tools you’re told to use but also learn about the tools that many others are using. Try to be full-stack versatile rather than just really good at one tool in the much larger process.
I don’t think the word “common” should apply to one dude’s anecdote for one company.
It’s true that C++ is very large and everyone necessarily uses a dialect of it — their own unique dialect. But learning the STL, for example, would pay dividends in most C++ shops.
Outside of C++, this advice is pretty much completely inapplicable.
Exactly. Some time ago, I used Qt at a job and thus I put "Qt (C++)" on my resume. That was not a good idea since like you said, Qt is its own "C++ dialect".
Same goes for Python, but to a much lesser extend. I only used Python in embedded projects. A bit of byte manipulation, drawing some plots, etc. Later I got people asking me to help them with their Django-based website, expecting me to be productive from day 1.
> If it's not a company-specific language, its range of use and ecosystem are probably so big that you can't know which parts of it will be used on the job.
> There will often also be rules about which parts of the language you're allowed to use, and how.
> With all respect: If you learn modern, beautiful, idiomatic use of some programming language, you're probably not going to see it on the job.
This doesn't resonate with my experience at all. It probably depends a lot on which languages were talking about, but the languages I've spent the most time with have pretty consistent best-practices across the industry (there may be a handful of different philosophies, but they're usually not hyper-specific to one company). I think the author is over-generalizing their experience
We are an elixir shop and we never advertised for Elixir devs. Instead we looked for people who knew Javascript and one other language.
That works well. We find the people get up to speed completely in Elixir in a matter of weeks. And are quite fluent by the second month. There are a few people who just can't grok it and they were generally bad programmers in the first place.
But if you're a shop with an obscure stack - never insist on someone knowing it as a condition of employment.
They should know the environment well (Linux, Postgresql, Javascript, HTML, SQL, etc) and they will be fine.
Don't learn a language but learn tooling? As in learn the most likely thing to be completely tailored to a company's specific processes, undoubtedly using something you've never used before, and impossible to actually practice on at home with learning or side projects? That makes no sense, especially for a software developer.
This advice may make sense for some languages, but it certainly doesn’t make sense for Python.
Python generally provides one and only one best way to do things. With one exception (single quotes vs. double quotes) I can’t think of any cases where my company didn’t espouse or require using regular, idiomatic Python.
My company consistently preferred using expressive features do the language. For example, using list comprehension instead of for-loops.
After learning Python, reading up on the frameworks used at my company (Django and Django Rest Framework) would be the next best use of a new dev’s time.
This advice might be specific to Django and Django Rest Framework. Both frameworks are old, popular, and opinionated; other people have thought through the best way to do things.
Understanding all the packages in the standard library is by no means a requirement, but knowing the language itself backward and forwards pays enormous dividends when debugging.
The "one way to do it" slogan was useful when comparing to Perl (TMTOWTDI), as it highlighted different philosophies (understandable vs expressive). I think it is wrong to take it literally. There is many different ways of doing the same things in Python.
My experience over the last 20 years has been very varied, I would say this applies more for some languages than others - particularly C++. Also more at large, established firms than smaller startups, which are more likely to want to use modern idiomatic practice in whatever language it is.
I haven't joined a new job in over 30 years, so what do I know.
But having seen quite a few come (and go) it seems to me that some context knowledge helps with getting up to speed.
It's not so much that ypu come in knowing the language (most don't) but doing a bit oc research, perhaps watching some videos, all help to learn the jargon. This can mean a faster learning curve when they tell you the important stuff.
Certainly the externals help. Can already use Git, know their way around SQL and SQL tools for inspecting databases, know something about database design (3rd normal form) - you don't have to know any of these, but it helps to hit the ground running.
And of course you can easily find out topics that might be useful by, you know, just asking in the interview or later.
What IDE, or text editor do they prefer - knowing your way around that will help you hit the ground running.
Regarding the list of Version control; Testing; Deployment / continuous integration; Databases; and Log management and search:
If you are studying CS at college/uni, and you're not taught these things already, then definitely go study them in your free time - people in the real world use them, and it looks good if you've at least heard of the concepts in a job interview.
Depends on what language you know. My first language was FORTRAN (and matlab) and my way of thinking was severely handicapped by the language. My code would be a typical 5,000 line routine with GOTO statements, that worked, but only I knew how to navigate that mess.
After I learned C++, suddenly the non monolithic doors opened for me. I also think that people who write c++ write better code, you get to read better code and follow better practices. Python, ruby, go, rust, javascript all clicked very easily afterwards.
I still have one more hill to climb, functional programming.
Absolutely hate reading job description seeing languages/libs/frameworks that aren't suitable for application the business is trying to accomplish. Apps where UI suppose to be light and fast? BAM, using the bloat view lib. Apps suppose to have minimal api surface, BAM, using unnecessary crazy query component in front of RDMBS. I just can't make myself apply for jobs these days. Bite the bullet and learn marketing bs stuff to sell my own software and no longer worrying about bullshit toolchain is probably a good trade-off.
I think if you're going to spend time studying before you start a new job, spend that time studying whatever you find technically interesting about the job.
If it was the choice of language that drew you to apply, learning about it is not going to hurt!
Yes, get really good with at least 1 language you like, and get acquainted with languages you know you will need to use, but don't think that you must master all of them or that you can't pick them up as you go. In general, languages share fundamental features and constructs, and there comes a point where learning a new one is mostly a matter of figuring out how to accomplish something with a different syntax or paradigm. This is why taking time to explicitly learn about a language without a more precise goal can be wasteful.
> Meanwhile, there is a likely source of confusion you can often address in advance: tooling. Ask about what the team uses for: Version control; Testing; Deployment / continuous integration; Databases; and Log management and search; Metrics (thanks, dukodk!).
>Sometimes these will be proprietary, and sometimes they will not exist.
Yes, ask this during a job interview and if they don't exist, seriously reconsider if you want to work there.
It seems like getting a copy of their coding standards (if they have them) would allow for more focused exploration than just asking which language they use.
What this article says is not generally true: get a job at a decent company and they’ll want you to use their language elegantly and sophisticatedly. (My experience is with US tech companies).
In my experience both as a developer and later as a manager, learning "on the job" never led to a good outcome. The (implicit or explicit) deadline pressure always led to the most shallow comprehension, weak scrutiny of Googled code and 'first hit' adoption of libraries or other secondary assets, very slow error correction and a cascade of (I hate the term) "technical debt" (which in the same paradigm should be called "technical theft" as we all know no-one ever will "repay" it).
What I wish I could figure how to reliably measure when we get around to hiring a replacement:
- do they care? They don’t have to agree with my opinions. We can hammer out a compromise with enough laughs. I just want them to care. Because there’s still a lot of things that even the best protocols, procedures, and practices can’t cover.
- can they be responsible? Or have they bought into the fantasy where they offload responsibility to a “decider” while they play the role exclusively of “doer”?
- can they and will they ask questions?? To customers, to teammates, in online forums, wherever. Or does their insecure ego prevent them from feeling the fool so that they can become the wiser?
-can they be critically honest? Admit what they don’t know when debugging, avoid conclusion jumping, candidly self asses? Or do they need some form of myopia to maintain a narrative about their abilities, their contribution, their value, or the environment around them?
If I could reliably convince myself that someone scored strong in these four areas, and had rudimentary programming aptitude we could just skip the rest of these “hiring/new employee” diatribes.