A common trap for people entering programming jobs
natemeyvis.com
natemeyvis.com
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.
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?
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.
Most businesses are also reluctant to give their best workers a meaningful raise.
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.
> "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.
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.
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 guess count yourselves lucky you've only had bad POs and not bad POs and bad developers.
In a simple project a mockup can be enough, but then what do you need a PO for?
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.
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.
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.
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.
This only applies once you make enough money to be comfortable. Before that point, money directly correlates to quality of living.
I've had a team member that was quite high in 3 out of 4 categories and low in actual programming skills and I found him to be a valuable team member.
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.
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.
Convince me to fix it.
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.
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.
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.
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.
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.
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.
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.
I'm reminded of this book
https://web.archive.org/web/20090901204114/https://www.nytim...
https://www.corinnemaier.info/english/
Of course, you work to pay for the rest of your life but I think there is a role for craft and teamwork in all of this.
I don't think anybody here talks about employees caring about or loving their employer.
It's about about worker caring about their work.
Because if I don't care, this is what happens:
if input == input_that_causes_bug_1948348 {
return static_output_for_bug_1948348
}
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.
- 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
Eh, nearly every worker will given the time and ability will do the proper solution. I have NEVER seen "workers caring" to be an issue in practice.
The reason code starts to smell is nearly always management. If boss says to quick fix, quick fix it is. The fish always rots from the head down.
Where you are perhaps. But there are still pockets of civilization left on this planet.
Well, that's just plain wrong.
At least make that worthwhile. Make this time count for you. Make it something you care about?
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.
(Super useful comment huh?)
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!)
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.
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.
- do they communicate about their work?
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.
A lot of management will praise B (good job, you saved our a..); creating a very very wrong perception.
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.
But it matters less whether developer knows django or node js or Java.
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.
I will just add one more;
- Can they learn on their own?
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.
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’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].
[0] https://littlegreenviper.com/miscellany/leaving-a-legacy/
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.
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.
I'm in august company, and enjoy the community.
- 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.
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?
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.
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.
https://www.informatics-europe.org
https://www.ordemengenheiros.pt/pt/a-ordem/colegios-e-especi...
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.
Start with https://guia.unl.pt/en/2022/fct/program/1053#structure and follow up with https://guia.unl.pt/en/2022/fct/program/1059#structure.
Before the Bologna changes across EU, those two were a single degree.
- 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.
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.
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.
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.
Why would you want law suits against software developers to be more common?
Without health inspection, those steaks aren't probably something you would feel like eating, if allowed to look into the kitchen.
When it is cheaper to ignore quality, business will do so.
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.
That is my point of view, and applies to how I would like to see software development for anything, including ToDo apps.
So you see, we aren't going to agree.
What possible good could ever come from involving the force of the state in something a trivial and banal as a todo list app?
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.
(*) except for PEs, which except for a handful of industries no one really cares about
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.
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.
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.
"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.
23.3% percent of respondents indicated that they use Vim in this year's Stack Overflow[1], noting specifically:
> PyCharm is used more by people learning to code (26% vs 16%) while Vim is used more by Professional Developers (24% vs 16%)
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.
I don't think there was any mention of Vim as main editor in this thread. Just that it's helpful to know it, and I think that makes sense.
> Most people still joke about not being able to exit Vim.
Most people make boring jokes. To me that "exiting Vim" joke is becoming even more annoying than the "only 10 kinds of people" one.
I presume (and hope) it's not your last project.
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.
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.
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.)
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".
> 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.
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.)
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.
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%.
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.
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.
Companies mostly hire for frameworks below the FAANG level.
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.
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 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.
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.
> 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.
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.
Probably until they become the established firms!
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.
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.
MIT calls this kind of thing the missing semester: https://missing.csail.mit.edu/ It really shouldn't be.
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.
I worked for a BI company where metrics was only for the CTO, not the deveolpers.
The screen on the wall for the cloud team was showing the build status of another teams project.
And anytime there was a problem, it wasn’t known to the team, until the CTO came to the team because someone had complained to him.
Both interperting and creating useful dashboards should be part of any team.
If the VCS is something other than git at this point, consider not working there.
In a previous life I worked at a successful 30-person company. We used SVN and just didn't think the migration to git was worth it.
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.
>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.