Things they didn’t teach you about software engineering
vadimkravcenko.com
vadimkravcenko.com
> Code is secondary. Business value is first.
I wish I could shout this from a mountaintop. If there's one thing I could change about engineering culture it would be this. But then again I would lose my edge if everyone understood this, so maybe it's best that they don't
Engineers: If you want to stand out in your career - take this to heart. Code is not the goal. Money is the goal, code is a tool to get the money. You work in a capitalistic business, whether you like it or not. Push your colleagues to build the thing that makes the business the most money, not the thing that is the "best" engineering solution. You will get tons of pushback on this - but eventually your pushing will bubble up to someone who works in "the business" (directors, executives, etc) and not just other engineers and they will invariably support you. This is your contrarian view now. This is your answer to Peter Thiel's question "What important truth do very few people agree with you on?". And you will thank me in 10 years.
Can you whip up a quick & dirty feature that might generate more revenue if released tomorrow? You can bet it will be done. At this moment the engineers who know when/where to compromise stand out.
[1] companies with a strong ethos or social mission do exist. If you find one that makes you happy, hold onto it :)
- Is it the business owner's goal? Depends on the business owner.
- Would the CEO have a better company if they focused on building something great rather than extracting money? Depends on the industry (the premise of capitalism is yes, but unfair markets are a thing)
- Is it (betterment of society through engineering) a valid personal goal to have on a strictly moral or ethical level, with no need of evidence or efficacy? Sure, absolutely
- Are people who focus on "extracting money" sheisty MBA types who lie through their teeth and exaggerate every number and kill the company in the process of trying to self-promote any random thing they can control? Sounds like a leading question...
These are all worthy distinctions imo.
I don't buy the altruistic motives.
It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity.
Technical debt is a real thing. As is "decision debt" (not sure the official term; I mean where you make the wrong long-term choice because you didn't spend enough time on research / prototypes. For example:
* Using Python because it lets you get something working fast. Oops three years later you're locking into Python and your app is slow as hell. You now spend all your time profiling instead of adding features.
* Producing documentation and commenting code. Don't need it now. 10 years later everyone that worked on the code has left, nobody can understand it and you have to start from scratch.
* Investing in tooling.
* Using Bazel. It's so complicated! We'll just use Make. 5 years later a CI run uses 300 compute hours and 6 wall hours, even for fixing a typo in the docs (these numbers are not made up).
Does those things produces no business value in the short term. But it definitely does in the long term.
Maybe that's not what you meant.
I'm not. I didn't say anything about speed. I am talking about deciding what to build. All of your examples lack the context of what is the best at making money for the business. You can't properly make a decision about addressing any of those things without considering the bottom line effect. Fixing performance for the sake of speed is not the right decision, unless your users are leaving because of speed and causing dollars to be lost. Technical debt is everywhere, prioritize fixing the debt that is causing monetary harm, ignore the rest of it.
"build the thing that makes the business the most money" is exactly what I said. And yes there's obviously plenty of nuance to that, especially when it goes "meta" and you get into tooling and platforms and tech debt and whatnot. But as a guiding principle it is inarguably advantageous and surprisingly rarely held (in my experience).
- Don’t rewrite the architecture with microservices when the monolith is working fine
- Avoid rebuilding the company blog on the latest CMS unless there are good business (time/money) reasons to do so.
- Choose boring technology, which would be the ones that most of the people on the team already know, and probably not the cool new language you heard about last week. Avoid fragmenting the tech stack to keep things operationally simple.
This is just a guess though – if you have some examples from your own experience it would be great to hear about some!
For instance on your last point - I've heard that used to argue against any new technology even if it solves real problems. Rust, Bazel, React, Typescript, etc.
I would go so far as to say some of these general principles can be harmful because they are mostly used as a lazy way to defend bad decisions. E.g. "premature optimisation" is more often used to justify ignoring performance entirely than it is to stop people writing things in assembly or whatever.
"But it might be a million items later!"
Yeah, or the company might pivot before we ever go live with this feature. Just slap a for-loop in there and get on with your day.
Or your app continues to be perfectly usable like almost all Python apps because you’re not doing something CPU-bound in unoptimized code, and you’re not seeing YouTube/Instagram-level growth.
Performance is a real consideration but the better way to approach it is to make sure you understand the bottlenecks in your architecture and have a reasonable plan for replacing code when you need to. I’ve seen more failed apps in fast languages because the developers took so much longer to build things that they never found what users wanted or the performance problems they actually had weren’t what they expected so their Go code being 10% faster mattered less than taking months longer to reach feature parity.
There are situations where performance is critical on day one, of course, so part of your value as a senior engineer should be recognizing which situation you’re in and balancing those needs with your staffing levels, too. Your Bazel/make example is similar: if you’re seeing that kind of performance hit either something’s gone badly astray or you have grown to the point where you can afford to have someone dedicated to setting up more advanced tooling because they’re supporting hundreds of developers.
Honestly I have yet to use a significant (like >10k line) Python app that wasn't really slow. It definitely doesn't require YouTube scale.
"Just optimise the bottlenecks" is generally a myth in my experience. Most programs are all bottleneck.
You should pick short term. Pretty much every time. The tradeoffs just don't make sense the other way.
There's a 9/10 chance the thing you're working on will fail or not achieve any sort of scale. Opting for short term productivity will let you find this out faster, and save you millions of dollars and years of time over your career.
When you hit that 1/10 product, you will experience some pain. But you now have enough information to justify dumping the resources (including political capital) into a proper long term solution.
There is a neat little trick I learned. Wait until leadership is under fire from customers and/or investors regarding the thing you thought might become an issue, and then present your solutions. Once you have proper buy-in, you can likely move way faster than by trying to constantly side-channel things through existing processes.
Spinning hypothetical tales of doom in order to be granted permission to build something shiny is probably the #1 thing that slowed me down in my career.
I've noticed this as well. It's amazing how many road blocks an executive trying to save their reputation can clear for you.
Precisely. The grandmaster software engineer learns to manipulate organizational inertia, fear and egos in order to achieve their goals. Simply detecting when someone has their heels dug in on something will take you about 80% of the way there.
Showing up to the 5 alarm fire with a perfect solution that can be deployed within 48 hours will make you look infinitely better than if you engage a months-long headbutt session with your managers about potential fires. Prepare your magic in secret and reserve your hope. If you are right, it will pay out. Be patient.
There is no such thing as "do it right". There's your flawed and biased perception of what's right, which doesn't take unknown unknowns into account.
> Oops three years later you're locking into Python and your app is slow as hell
Been using Python more than a decade, never had this problem. App slow as hell is always an eng culture problem. Shitty engineers will write slow code in any language. Don't do HFT in Python, don't write web apps in C.
> Producing documentation and commenting code. Don't need it now. 10 years later ...
The need for documentation doesn't skyrocket from 0 to 100 overnight.
Don't need it now? Don't write it.
Starting to feel the need? Start writing a little bit.
The problem is not the decision to not write documentation. The problem is not re-evaluating this decision in 10 years.
(another problem, based on your take, is treating documentation as binary: we either don't do it, or we're going all in)
> We'll just use Make. 5 years later a CI run uses 300 compute hours and 6 wall hours
Do you think every team that uses Make has this problem? Again, sounds like it's a team problem, not tool problem.
For me, the game theory gets pretty advanced at this level.
My strategy now relies on enriching myself via equity and careful product decisions so that I can then go start my own software studio and do things my way. Presumably, this is what our leadership wanted all along.
Trying to get my rush experimenting with new ideas under the current employer is really only shooting myself in the foot with regard to this long term plan. Any experimentation is reserved for side projects and weekends. At this point, I only bring "code" ideas to the team if I think they will legitimately improve the business in some eventual way that a non-wizard can understand.
Code and business value are worthless. Boss approval is literally everything.
It really doesn’t matter if your ideas make a ton of business sense if they are in conflict with your direct manager or any part in the chain of hierarchy. As long as they don’t like what you’re saying - you’re literally worse than worthless. Often this is because your idea isn’t their idea - therefore damage to ego. Damage to ego means get that guy out of here and make sure I don’t hear more from them.
People need to understand that you’re hired for a job. You’re a glorified and well compensated code monkey. Even at $1m/yr - still a god damn code monkey. You jump when they say jump.
I’ve yet to meet any hierarchy chains that are truly open minded to a low level IC saying anything that counters them. I’ve worked at quite a few places too and talked to a lot of folks about this.
You’ll thank me in ten years because you’ll become a bootlicker and actually make progress in your career rather than being stuck in senior/staff until you burnout from the industry.
if you don't want to be a jester and you want satisfaction doing a good job professionally you need a union
Thankfully sometimes 'they' are the customers paying real money for a product or service that's valuable to them.
But as you say, larger organizations have more room for political distractions on the way to giving that customer what they want.
This is such a sad corporate loser mentality.
Bosses are humans. They can be wrong. They can be convinced. Even manipulated, if that's your game.
> you’re hired for a job. You’re a glorified and well compensated code monkey
Only if you choose to treat yourself like one. I'm hired for my domain expertise that my bosses lack. I can understand 60-80% of their domain, they can understand 5% of my domain. When I'm saying that feature that they want is a nice-to-have and I don't want to build it unless I see evidence of it's value, they usually listen.
> I’ve yet to meet any hierarchy chains that are truly open minded to a low level IC saying anything that counters them
I worked at multiple startups (between 4 and 100 in size) and I always had a voice, even early in my career. Maybe you're the problem?
> you’ll become a bootlicker and actually make progress in your career rather than being stuck in senior/staff
Where exactly does the bootlicker progress? A code monkey doesn't become VP/C-level through bootlicking, there are plenty others with much better soft skills. At best you'll be a code monkey turned manager (which is worse than staff).
Capitalism and money are actually only the means to an end, to achieve the best possible for society. But as is so often the case, at some point the means becomes the end.
It's about a means of allowing wealth disparity while the have-not masses are too distracted to get out the guillotine
It is not about what capitalism is about, it's about why society chose capitalism instead of other forms of economy.
That's why capitalism needs laws to tame it's worst excesses.
For me it's that Apache is the best web and proxy server, Java is the best programming language and platform, Eclipse is the best IDE and never use anything made formerly or currently by Russians including nginx and JetBrains' stuff.
On the flipside, you can be like me and be "meh" about business value (or at least, not a maximalist about it) and treat code as the point and fun/art/etc (easy to do with an FP language, for example). You'll still deliver value and even squeak in some fancy code that isn't the best business value.
The result? Over the years, your employer(s) effectively subsidize your code-for-fun's-sake using the money they make from business value others focus so much on :)
And that's equally true of everything from programming to design to writing. The value of a newspaper article is often the story it tells, not the actual way it was written. Same with a video, film, tv show, design, or whatever else. Most people don't care how good your technique is or how elegantly the product was made, they care about whether it does something they care about.
Also, maybe my perspective is skewed from only ever working at gigantic companies but what usually grows a career is making your manager's life easy - becoming someone who reliably gets shit done on time and without drama.
I think most engineering teams will have a "backlog" of tech debt. Some are things they want to do (the original implementation is icky but could be lived with for years until requirements change) and some will save the team hours per week in distractions/maintenance.
Being able to evaluate the actual impact of the "tech debt clean-up" and pick the one which helps the business will absolutely set you apart from your peers.
Now you say measuring the money it makes is the way to go.
Money is not the goal. Money is just another tool. Like VSCode.
>eventually your pushing will bubble up to someone who works in "the business" (directors, executives, etc) and not just other engineers and they will invariably support you
MBA-driven development when
You can never go wrong when optimizing for profit above all else.
This is an obvious and empty statement if it's not used in specific cases. Unless you have something new to add in the "how to get money debate" the distinction between "code" and "value" is irrelevant.
When I've heard this, it's typically way to trivialise engineers and shut down discussion. "I don't understand how this contributes value, therefore all your contributions are worthless."
What value does that bring to us or our customers, versus the money spent on doing that.
Many devs tend to forget that features can be measured in time spent on X multiplied by hourly rate.
Rather this:
> Code is secondary. People are first
This is easily overlooked. Your social skills matter most. Leading, listening, communication. Most problems are people problems.
Rare work-life balance. In other professions, your work day ends at 18:00,
and you forget about the job. Not here. You will most likely always be
online and checking the code, even in the evening.
As for our industry, I don't disagree with you but I'd be a bit more nuanced. I'm not pressured to work long hours. But I often feel that if I want to reach my goals, I need an occasional coding marathon (which I don't mind because I do like coding, like everybody else doing this job I suppose).
An occasional coding marathon is fine. I've done it myself, but I don't expect it of anyone else, and if it became a routine expectation (as it seems to be with the author of this post), I would consider it a major red flag.
If you're so uninterested by your work that thinking about it after 6pm makes you sick, why did you pick it?
I've been in the industry for 15 years, coding since 25+ years, and I very often think, code, read about work or work related things at any time of the day or weekend or vacation, because I find it interesting. Why would I work in something of no interest to me?
If you're so uninterested by your work that thinking about it after 6pm
makes you sick, why did you pick it?
I've been in the industry for 15 years, coding since 25+ years, and I very
often think, code, read about work or work related things at any time of the
day or weekend or vacation
You are admitting that you do think about code outside working hours, though you don't consider it to be work because.. it's code for a hobby project?
That's not a valid point to me. What if your job was open enough that you could find dozens of interesting fun things to code on the side?
That's the job you should be looking for.
What if your job was open enough that you could find dozens of interesting
fun things to code on the side?
I have some days packed with meetings and calls, and I actually find it
refreshing/relaxing to work on more down to earth matters in the evenings or
weekend.
Mine is.
Working outside of business hours is not the same as overworking.
I have some days packed with meetings and calls, and I actually find it refreshing/relaxing to work on more down to earth matters in the evenings or weekend.
Sometimes I even take vacations just to code on some work-related projects that I find super interesting and wouldn't have enough focused/dedicated time on normal business days.
Overall the whole hard distinction between work and non-work is overstated IMHO. I choose my work places because I genuinely like what I would do there.
I will even go further: If I end up with colleagues that are _not_ genuinely interested in what we do to at least think about interesting problems in their free time, then it's a bozo job, I don't want to work with these people. Nothing great has been achieved by teams where people shut down their brain after 6pm.
Now don't get me wrong, I understand that there are gruntwork places out there, where the job is writing braindead CRUD apps all day long, and I wouldn't want to think about it after-work. But then again, I wouldn't work there on the first place.
Nothing great has been achieved by teams where people shut down their brain
after 6pm.
1. Thinking about work
or
2. Shutting your brain down
If I want to go hack on some Clojure after work, when the day job is in Python, then what's wrong with that?
That is of course perfectly fine, but to me that represents a not-so-ideal fit between your interests and your job.
Realistically, you will spend more engineering time on your job than on your hobby project.
From my experience, that means my out-of-working-hours projects tend to be driven by needs or limitations I encounter at work.
I then find it more optimal to embrace and leverage that relationship between during-working-hours and out-of-working-hours projects.
This is the best of both worlds, you get work on more green field projects, have flexibility to choose what you work on, under the constraint that it solves something for your job, but under the assumption that your side projects are anyway often inspired by work, it's a fit by construction.
Let me give you an example:
Some years ago I used to manage some high performance computing cluster, with storage nodes attached to compute nodes as the jobs were very IO intensive. We used glusterfs, which at the time got acquired by RH and maintenance stopped. Me and a coworker started to dig into glusterfs to solve our issues. We spent months reading the code on our free time, reading papers on distributed filesystems, fixing issues in our fork (hoping that RH would pick up maintenance after the transition). That's an example of an out-of-working-hours project, inspired by work, that got used at work, and thus counts as work, while still being very interesting.
This is just an example, but overall I kept that mentality and have been doing that kind of things for more than a decade. You just need to find the right job where you have 1) interesting problems to solve that inspires you to do more 2) the freedom to push your projects 3) the drive to work out of office hours to prove that your projects are worth it and push them.
All the colleagues I have respect for do the same. And someone that does not have this spirit, for me, is not someone I want to work with.
That is of course perfectly fine, but to me that represents a
not-so-ideal fit between your interests and your job.
Me and a coworker started to dig into glusterfs to solve our
issues. We spent months reading the code on our free time, reading
papers on distributed filesystems, fixing issues in our fork
(hoping that RH would pick up maintenance after the transition).
I love programming, but I love my family even more.
Do you spend 100% of the your non-working hours with them?
I manage to have a job, spend time with my wife, my kid, learn guitar, code & think on my free time, and I run 3 times a week.
I don't watch TV though ;}
I do 1 to 3 runs per week, between 45m and 1h15 each.
I have a guitar teacher coming 2h/week, the rest of my practice is random: could be from 0 to 6h per week.
Since I basically WFH 100%, I have no commute time, which helps a lot.
> what we do to at least think about interesting problems in their free time, then it's a bozo job
> Overall the whole hard distinction between work and non-work is overstated IMHO
Look, I continue to code and study in my free time, and I am still passionate about learning SoftEng and CompSci fundamentals, but the shit you're saying sounds super-sad and I definitely wouldn't want to work with someone who takes vacations to work on _work_ problems, either.
I'll take a seasoned and passionate engineer who has a family (even though I don't have one!) and has to work around that any time of day. In the vein of what GP was saying, bounds on limited resources like time can produce very effective work habits and conversely, seeing time as an unbounded resource (which is a phallacy anyway) sounds like the recipe to have a culture of sociopaths.
I worked 7 years about 60-70 hours each weak for customers which „are so important“ to work at weekends.
No one will give you the time back you could have spend better by developing yourself, family time or staring your own carrier. But working for a company is most of the times lost time.
Yeah, not quite as quick off the mark as you youngsters :-).
I posted a similar comment to yours in 2021: https://news.ycombinator.com/item?id=27065714
Grass is always greener.
That's great and so do I, but I still don't see that as reason to work in my free time. I do some personal projects as well, and those are usually even more interesting but also more beneficial for myself. Of course I still think about stuff from work now and then, maybe I see an interesting solution when casually surfing the web, but I'm not going to do more about that than write a note for the next work day.
> Nothing great has been achieved by teams where people shut down their brain after 6pm.
Citation needed
Edit: Also most teams never work on the next exceptional thing that will be remembered in 30 years, so why work as if it was?
- management pretending to be a wagie as a psyop
- extremely privileged and never had to grit your teeth to pay the bills
- going to have a rude awakening when the crop of younger millennials and Gen Z hits your workplace and you realize these bright young things with dreams and desires are only in software because it’s one of the few lucrative careers left in this proto-fascist shithole of a dying civilization.
As far as fascism goes, as you say, these things need time… but I’m sure a yet unwritten history book can enlighten you, right next to the passage on the gen Z backlash.
This is not really relevant, I was merely provoking emotional response for rhetorical effect (a useful and effective tool in the business/realpolitik toolkit)
And I’m sure these younger engineers are happy collecting their paycheques, scheming their schemes and thinking of what to disrupt next with all the free time they have because they roll their eyes at guff like the parent comment. Maybe that’s how we can all be happy.
I love being a software engineer, still, my family is orders or magnitude more important than my employer’s codebase. I really don’t care about my code architecture issues at work when I play Legos with my son or when I ask my wife if she had a good day while cooking together.
And I say that while currently working for a good employer on interesting topics.
I'm describing passion.
> love being a software engineer, still, my family is orders or magnitude more important
It's not mutually exclusive...
I wake up at 6am, usually because that's the time my son wakes up. I spend around 30m with him until my wife takes over.
Then I work on some stuff from 6:30 to 8:30 before the rush of the day starts.
My wife does her morning yoga starting at 8:30 so I take care of my son from 8:30 until the nany arrives at 9am.
I do my work day WFH (with some pauses to play with my son or chat with my wife) until 6pm, then stop to spend time with my son before he goes to bed around 7pm.
I cook, eat and discuss with my wife between 7pm and 9pm.
We usually then head to the sofa where she watches a movie and I sit next to her reading/coding.
She will go to bed around 10pm, I usually continue to work/code/read until 11pm/midnight.
3 times a week I swap the cooking part to go running for an hour. Or I do it at lunch time.
Overall I spend quite some time with my wife and child, while still working between 2 and 6 hours more per day.
I really don't think I have a crazy schedule, nor that I don't spend enough time with my wife or child, or doing sport.
And there is also quality vs quantity. Each family is obviously different.
As friendly advice, have an open conversation with your wife about that. Speaking from personal experience, I definitely had months where I thought I was balancing my time well enough and my wife disagreed.
It's as though the absence of religion in modern life has left a vacuum of comradery and dogmatism, so they let work fill it.
Keep in mind that many people are passionate about multiple things and it is ok that they are not coding related. Please, just don’t assume I am not passionate about my job if I spent “only” 8 hours a day on it on average. There are just more things I am passionate about and I have only one life to live.
I would love to be paid to pursue my passions full-time, but that opportunity has not yet arisen. So I split my time accordingly between doing what earns me a living and doing what I actually enjoy in life.
So you don't really stop working at 6pm..
And it’s not about wether I like my work or not, it’s just that I have more important things to think about or that I just let my mind wander.
I already spent most of the day on the problem, and that exceeds my natural interest in it.
I think I'd like a job with truly flexible hours: work all evening on something if it's occupying my thoughts anyway, but then get a full 'evening' to chill, full night's sleep, and start the next day when I'm ready. I can do the former, but I'm still going to be expected to dial in ~to pointlessly summarise it~ for stand-up in the morning. (No I don't have young children, yes yes this wouldn't work for everybody.)
I've started billing that. Not always, rarely in full, but I bill some of it. It's not just for the money but started more like "what exactly do I work? Best way to know is to bill it".
I often think about code at night but only in the context of a personal project.
Taking care of your headspace and unwinding at end of the day should be one of the most important routines in a programmer’s life.
Honestly even 99% of non-nuclear reactor code doesn't need on call. Most of the time it can wait until the morning. Amazon? Sure, have on call. Your app that's used by businesses during the business day? Fix it tomorrow.
If I'm managing this one, then you're definitely going home on time and getting a break from work each day.
I tried to tell him: Nobody asked this of him. He didn't need to prove himself, it wasn't on his back if we didn't meet the deadline, it wasn't worth sacrificing his health and the relationship with his wife and more than likely burning out before 30.
When I start a new job nowadays I don't install teams or slack or connect my work email to my phone. If I have messages waiting in the morning I just address them then. If anyone complains, oh well.
Please name another career that pays you six figures out of college that doesn't involve several years of additional education, doesn't make you wear suits, is mostly non-life-threatening, is constantly in demand, and doesn't require special accreditations or certificates.
If you're spending more than your 40 working and aren't on call, then that is on you 90% of the time, in my experience. I have definitely worked more than 40 some weeks when I'm pushing through something, but there have been plenty of times where I worked less.
If you can't find advancement in your current role, then that's also on you. Not that this matters, as finding a new job in this industry is insanely easy relative to other professions, and they'll usually pay more for your skills.
IMO, you should ALWAYS be thinking about what you need to do to get to the next level, if career advancement is a priority. Everything you do should be in service to demonstrating capability in performing above your station and providing business value/revenue generation. Brag sheets and being vocal help a lot.
I am biased; I absolutely love what I do and wouldn't trade it for anything.
It’s not a dream job everywhere for every person. Not everybody is able or has the ambition to put in the work needed to be a top earning or top skilled developer. And even if you are a lot of the “dream” aspect of the job will depend on what country you live in, even in a remote-first world.
But if you’re in America it’s one of the last professions where the American Dream is still possible.
It’s a trade, so the better and more experienced you get the more money you can demand if you’re ambitious. Software also scales better than any business so your work can have an incredibly high level of impact.
https://www.amazon.com/dp/1484290410/
https://www.whyprogramsfail.com/
That can mitigate that a bit.
Often debugging is a hunch, and quickly branches. One person will go down the path of trying the same site from another PC. Another will try a different site from the same browser/PC. Another will try to ping the server.
If you're running this live you're always going to have the chance where someone's hunch or first try basically pinpoints the problem and eliminates a dozen checks from their consideration. If you're looking for things like "did they check DNS? Did they try another site?" but they skipped that and immediately figured out apache wasn't running, do they lose points? Or do they get 100% for their lucky (and/or experienced) guess?
If you do it on paper, the major problem is basically infinite branching for every step and possible result. How do you mark that? What's the minimum you need to do to get 100%? I think it's also unfair, because even as a seasoned vet I've been deep in troubleshooting to the point of (for example) greping source of nginx for a specific error message -- which I'd never have even thought of two steps earlier. I do t expect anything that complex on a school test of course, but the point is the result of each step is often the only way to even think of the next.
E.g. "I am going to ping an IP on the outside first, to see if ICMP message reaches the outside server. If yes I will check if the DNS server responds, if no we check the physical connection."
That would be an ideal answer, judging less ideal answers fairly is certainly a challenge, but not impossible.
Maybe there are multiple DNS servers for the zone that are returning different IPs, maybe one or both of them is even in split-zone configuration so it returns a different IP depending on if you're internal or external. Maybe the client has manual DNS configured or a hosts entry that's wrong.
Each of these problems would have several more layers of troubleshooting steps and branching, and it's not even a complete list -- and this is only if the problem is DNS-centric! There's hundreds of other branches for each of the other problem categories.
Of course in reality there can be more, weirder things — especially if you are coming into an unknown network. But we are talking about an educational context here, would not make a lot of sense to let your students run into new unknown issues on a test unless your goal is not to educate.
I have only been able to figure this about people after working with them for 6-12 months. Which is why it helps keep references to such people and have them on your teams in future ;-)
Even if you can gain such intuition through looking at a piece of code, in a realistic scenario, more often than not you don't actually know in which file or method the bug is hiding. What you have is a code base and some externality that is wrong, the debugging process is essentially deepening your understanding of the relevant code (in relationship to what it should be doing) until you understand what is wrong.
Debugging isn't being able to use a debugger or a profiler or syscall tracing tool or whatever, sure they help but the critical skill is being able to quickly and accurately model the behavior of a system in your head, in combination with a tacit understanding of where bugs tend to occur.
Give the candidate some simple code (~200-300 lines is probably about right) with a handful of failing unit tests. Sit them down, walk them through running the test suite and ask them to find and fix as many bugs as they can in 30 minutes.
It pays to make the first bug trivial (like, a typo or something) and make the subsequent bugs increasingly subtle. You learn an awful lot about a candidate by watching their process.
The hard thing with this sort of question is calibration. Candidates will be able to debug way less code than you think in 30 minutes. It helps to run the code past a few coworkers before giving it to candidates to figure out if its too hard a test.
The surprising thing about this test is that it seems to be really highly correlated with senior engineers. Senior engineers often don't do as well as smart grads at coding problems because we often don't write that much code any more. But senior engineers seem to do waay better than juniors at debugging problems. If I could only get a candidate to do one programming problem, I'd get them to debug code. I think you get a massive amount of signal about whether you'd want to hire someone out of a debugging challenge.
1. Your evaluation can be interactive: you're watching them step through, can stop and ask questions about their thought process, etc. If it's a theoretical problem (ie: not on a live computer) you can even re-calibrate on-the-fly if they're really quick (maybe a lucky guess) at narrowing down the issue, or just asking "what if this happened instead, what would you do?"
2. Grading the candidate is subjective, just like the rest of the interview process.
The OP was talking in the context of college-style evaluation. I don't think you can apply either of these things to grading someone in a course. (1) doesn't scale, and (2) isn't a fair (or unbiased) way to evaluate students.
I’ve done “prac tests” before when I was studying CS. The test happened in a computer lab. We were given some specs and had to submit programs which implemented the specs. (The specs were written in a way that grading could happen automatically).
Just do the same thing, except the student is given some code with some failing tests. Their grade is determined by how many of the bugs they can fix within the time allotted.
We can definitely test for basic debugging and troubleshooting skills. But I havent found a way to consistently evaluate people who are capable of identifying and finding solutions to complex problems. These days a lot of these come down to framework level experience. With the proliferation of frameworks and tools used in modern apps, it is impossible to find someone who can solve problems involving all of them. So in a big team you want a variety of such experiences to cover a wider base.
Having said that, I have been in many situations where i have had to join a debugging session involving technologies or programming languages where i have had zero prior knowledge and have moved things towards a solution by asking what at times seems like basic queries to help others come up with the solution.
One thing I do in job interviews is to have the candidate debug an issue (that they usually caused themselves and that I let them purposefully run into). Quite the eye opener of how they approach bugs.
Can you tell how long they wasted on the debugging aspect?
Nope. That's the problem. These are soft skills that are hard to teach but much harder to test.
And print statements are sometimes the superior choice.
This ties into my other comment that these things can be heavily subjective. As long as it gets the job done, I prefer print statements used by somebody who uses them as a sharp knife to gain understanding of what's going on over somebody just clicking buttons in a fancy UI but has no clue. (And vice versa, obviously.)
Print debugging is sometimes useful but sometimes indicate the person doesn't know about tracepoints/logpoints.
Imagine going to school to learn how to write, but in the course nobody ever reads anyone else's work. And in fact, most people (including the professors) never read any books. For some reason, thats the status quo in software.
In industry, learning to read other people's code is one of the most valuable skills there is. There's plenty of times I've run into a showstopper bug in some opensource library we depended on, or needed another feature that was missing. If you can't read code, how can you fix the problem? Hope there's another library out there which solves your problem better? Implement some complex workaround?
But if you can read - well, you can just dive into your dependency, debug the issue there and file a PR. (And if you like, use a fork with the fix until its merged upstream).
Currently I'm building something with sveltekit and i have no idea how to debug this except logging out messages.
You are missing out on a lot of amazing capabilities by avoiding the browser debugger. Did you know you can place a breakpoint that will trigger on DOM mutation?
For TypeScript, source maps can help with the debugging.
The live reloading dev server is just a wrapper around your code. You should still be able to use the browsers debugger to set a breakpoint at the function you want.
I remember finding a situation where output of console.log would not match reality when debugging using chrome's debugger while working on a react app in 2019. Had to resort to making a copy of the variables to get console.log working in that situation.
When it comes to web deveopment, like others have said, it is easy to debug modern web apps with the help of source maps. We have been doing some version of that for a long time now. I remember using source maps with codeview back in the late 80s/early 90s.
Discover that your greatest struggle is with your own deep rooted sense of insecurity,
I think that software engineering, like no other form of engineering, has an aspect of creativity (source code), in combination with many (often hidden) single points of failures (bugs), where cooperation with others is essential, causing all your insecurities to be revealed.
Either you learn to hide these or they drive you on a road to soul searching, possibly resulting in various forms of burn-outs, in alienation from your family and friends outside of you work circle, in changing your world view and/or losing your faith. But which might in the end result in a form of enlightenment.
I am aware that there are some other professions where this also is the case. Just this week, I watch an interview with the neurosurgeon Henry Marsh. You can watch it here (with some Dutch subtitels and advertisements): https://www.npostart.nl/vpro-wintergasten/04-01-2023/VPWON_1...
I also identified with the rest of your post. I've felt regret recently for the career "potential" I lost to the inner struggle, and at around 15 years in, I think I understand these dynamics well on an intellectual level, but emotionally, I feel further than ever from being able to overcome them.
It is probably better to deal with your insecurities, your deepest fears. With that respect, I think that the litanry against fear (from Dune by Frank Herbert) has some deep meaning. Making your fear larger, and than asking yourself what it would mean in the end, can help to overcome your fears.
Another things that I have discovered is that breathing techniques can help. Slow and deep breathing is a great technique for finding calmness. Many meditation techniques involves a focus on breathing. I think you don't need to sit with you eyes closed in a certain position and/or and think (or not) about certain things. It also works when you are sitting behind your desk or when you are walking around.
I think everyone squirms when asked to make a prediction with too little information. If you want to see a developer squirm. ask for an estimate for how long it will take to build a given product or feature. If you want to see a PO squirm, ask for an estimate (in $) of the expected cumulative revenues for the same product or feature.
Pair any estimate (time, cost, effort) with a confidence indicator. This will likely improve as more about the problem is known, but until then gives the ability to reason with appropriate certainty based on a set of inherently noisy priors.
There’s a whole set of more formal systems such as PERT (https://en.m.wikipedia.org/wiki/Program_evaluation_and_revie...) which base off this principle. That doesn’t work for every project, but there’s often an over correction in ‘modern’ software teams where significant research, experience, and process that has been designed to avoid project chaos is completely ignored for the sake of being ‘lean’.
Optimally we have a probability distribution.
Not to forget that over time the confidence will grow and estimates become more precise.
If we want to estimate accurately, it is necessary to break work down into smaller pieces. However, we can only estimate the items that we can identify at the time of estimation (I.e., we know that we need to do A,B and C but discover that D,E and F are needed as well).
The other factor is combinatorial explosion: we'll do A,B or C and this impacts what we do next. This graph can become enormous when attempting to construct up-front.
I agree that having a probability distribution for each estimate is better than a single value. If you have two values, this is a uniform distribution. It is also possible to do a normal distribution, triangular, truncated normal, etc. However, it isn't clear to me that increased sophistication leads to better outcomes.
The two value (estimate and confidence) is just a simple approach that is rather intuitive to interpret directly. As you note, diving into 3 point estimates gives to ability to extract beta distribution or other weightings that may or may not be suitable for the given domain.
Complete top down planning for any work that involves discovery is useless, at best. That doesn't mean no planning is better.
(Source: have experienced and been actively involved in both sides of that overcorrection.)
Product/feature value usually spans a larger range of values than time to build it, so you don't need to estimate value as accurately for it to be a useful guide. It's also often easier to estimate because you wouldn't consider building it unless you have potential customers lined up.
And then if the PO says "building this feature would earn us back 2 developer-months in the first year alone" it's usually very easy for a developer to judge if building it fits into that profit window or not.
----
Of course, nobody does this in practise because people suck at decision-making. The next time someone asks you "how much will it cost?" try asking them "how much is it worth our organisation? What are we willing to pay?" and it will be clear they have done zero analysis on cost/benefit.
People don't know how to analyse -- or are uncomfortable with analysing -- these things so they are looking to be guided by their emotional response to information.
"Elegant code, best practices, smart solutions, design patterns — these are done for the sake of your fellow software engineers who will work on the codebase after you rather than helping you fulfill the purpose of bringing value"
The fact that business is about money is a truism. The other fact is that, good engineers care about that AND know that good engineering - which requires 'some' obsession with good code amongst other things - leads to faster iteration loops, less bugs, better maintenence, less incidents and SLA breaches. Do you know what they all equal? That's right, money.
Believe me, crappy, inconsistent over-complex spaghetti code and poor engineering practices can really really hurt a company.
As ever it's a balance of course. Every decent engineer understands the trade offs. For my part, I think about the business goals first and foremost and, to achieve those, I make sure my code is as simple, clear, testable etc as can be when realising those goals.
It's often a dereliction of duty as an engineer to just get the job done without reasonable consideration of good practices. Building up tech debt? Sure, I do it all the time. But sacrificing what I know to be a good practice just to deliver? No.
Are they? At one time in my career you just let people know when something isn't going smoothly/not on schedule. A quick email (or equivalent) was more than sufficient to raise awareness.
For various reasons I eventually fell into this meeting culture. I don't get it. It produces this weird state where everyone saves up what they have to say for the meetings to avoid an awkward lack of participation or "I have nothing" in the meeting, which results in a barrage of mostly useless information, all while the nuggets of gold that the meeting would benefit from regularly get missed because everyone is too overwhelmed by the information overload.
And because everyone saves up what they have to say, the team seems more distant, which diminishes other beneficial outcomes that arise when everyone is regularly chatting with each other. The information lag also dramatically decreases the overall efficiency of the team, not having useful knowledge as it becomes available.
> You might not like it, but the information must be shared for the system to remain efficient.
The thing is, I actually like meetings. After you've recognized something isn't going smoothly, calling a meeting to formulate a plan of attack under the narrow scope of that specific problem at play can often lead to really great outcomes.
But I dare say that if the meeting is there simply to find out that there is a problem, you are doing something wrong.
This is an odd meeting culture. Just remove the requirement that everybody has to bring up something.
FWIW I've never felt like that in my teams.
After all, if everyone sent out their emails, so to speak, what would be left for the meeting? I mean, what are the odds of someone discovering something worthwhile to communicate to the team just seconds before the meeting starts? Any earlier and the email would have already been sent and there would be nothing left for the meeting. Maybe it happens once in a blue moon, but regularly across a wide number of people? No way.
I've never attended a status meeting that was completely void of participation, so there must be withholding of information done so to pad the meeting. Not everyone may feel such pressure, but it is apparent that some – and I dare say most – do.
I've not had this for the last 10 years, so it can definitely be removed.
Obviously everybody is welcome to bring up whatever is interesting nd worth discussing, and that's what we do in my current and previous workplaces. But there should not be a requirement that everybody has to bring up sth, which would lead to the described issues..
You’ve sat in regularly scheduled silence for the past 10 years and people still show up?
> Obviously everybody is welcome to bring up whatever is interesting nd worth discussing
But logically they would have already said it when it first became interesting, unless they felt pressure to pad a scheduled meeting with content, withholding information from the group until the meeting takes place. So, again, what’s the point of sitting in silence or purposefully denying the team information to satisfy the social pressure?
The original context was about meetings intended to let others know there is a problem. A time to allow you to say things aren’t going smoothly. But why would you wait for a meeting to let others know there is a problem?
The only reason is because you feel pressure to ensure the meeting isn’t silence. Otherwise you would have logically made it known long before. What is really gained in withholding information from the team?
But you're right that having a low priority Slack channel that you can casually look at when you're at a natural stopping point is way less disrupting than having to drop everything you are doing because the clock says it is meeting time.
I wonder sometimes if people who get engrossed into this meeting culture have just never experienced better? Anything can seem like a good idea if it is all you know.
One thing I've learned is that a lot of people simply don't read emails.
You can send out all the status emails you want, no one is going to read them unless it's directly related to their own work.
Short, frequent status meetings ensure that people are actually aware of the status and gives them a chance of unblocking you if they can.
In fact, there was once advocacy towards a style of meeting (oft called a "standup") where you explicitly called upon participants to give their status update because it was recognized that they wouldn't be paying attention and needed prompting to snap them back, although this has largely fallen out of favour as we realized that only kept their attention for the length of their update and didn't achieve the desired effect.
standups are pointless status updates where no one listens to each other.
even doc reviews, which can be useful, often get fucked because the clever folks with things to say can't leave them as comments on the doc so the owner had time to review and think about them.
save meetings for things that require actual discussion, not questions or status updates
The worst are when you run into code that’s been around for a long time, but obviously doesn’t work, but which have stuff built on top of it relying on it not to work.
When two bugs manifest together in one symptom, the engineering approach that you have learned about breaking a problem down and testing one thing at a time, might not be enough to find the issues.
All projects are chaos, learn to accept that and to navigate it.
Centralising things into common classes, methods, functions, libraries, modules or services, for reusability, and for less redundancy, also increases risk, as it is now even more important that that stuff works.
I think usually it's not a matter of not "wanting" to give them. It's a matter of not wanting to take a wild guess - which is talked down if it seems too high - and then be asked to finish the work in that time frame.
Time or scope, at least one of these things needs to be flexible, and stay flexible until the work is done.
You’re on the money about time and/or scope needing to be flexible. Estimates improve as you gather more information and complete parts of a project. Providing early feedback that relates to the original estimate is key!
“This is more complex because of X, and will likely add Y time. Do we want to proceed?”
Nothing worse than getting to the end of an original estimate and only then letting a project owner know it’s going to be twice as long.
Wishing upon a star that people are better is a terrible plan.
Wishing is indeed a terrible plan. Teams that treat estimates as commitments are dysfunctional. Estimates are a tool for budgeting in an agile-like world, and need to be refined as progress is made.
- Estimates (I think it will take X long)
- Targets (I would like to have it done by X)
- Soft deadlines (with low consequences for missing)
- Hard deadlines (with high, usually external, consequences for missing)
and that understanding the model and using those words solves quite a bit of confusion around dates. Of course sometimes targets become soft (or even hard) deadlines because humans are messy, but being able to distinguish those things is a step in the right direction.
Yep
> Rarely you're building something you love. More often than not, it's tedious work that needs to be done
You should switch jobs. The majority of my jobs were building something I love
> It's hard work. You're sitting behind your computer most of the day.
That's not hard. That's what I would do even if I didn't have a job.
Lmfao if they would hire me I would.
Most work environments will recognise the discipline and reliable work ethic and will leave you alone. Some environments will measure you by hours-attendance and will push you out or criticise your work methods. These are not healthy places.
Anecdote: I was learning about climbing and the instructor showed us a thin climbing rope chord (emergency back up). He explained it was plenty to carry your weight but comically thin. What might appear that it "would never work" sometimes can work. Hence my above advice to others.
To the points about time spent and business value coming first, I would defend them by saying first that companies of different sizes operate with different requirements for their staff. You were hired to code, but in my experience the code is only important when it's serving the end goal of value. It's up to you to make sure that you're providing value, so be fluid enough to know when not to say, 'not my job'.
As for the grueling time expectations, I feel a lot of commenters are reacting to environments like those you hear about game devs; of course that's not alright. But yes, if there's systems that you work on that no one else really knows about, you'll need to keep tabs on them pretty much all the time. It doesn't mean you need to check in all the time, it means you need to write code to tell you on weekends when your things need to be checked out.
The job I have now could probably be done by some ninja coder for less, but they pay me because I know how to deal with everyone who doesn't code while I write my code.
Zero times? It is crazy.
That's out of tens of machines, over several years of running linux.
I'll never experience that again. 8(
I just don't vibe with this advice anymore, like all the same with me but I'm gonna call myself something else then, you can have it.
This is an example of negative self talk, stop this, the reason you are broken is because you are trying to fix something, this just leads to more anxiety.
Most self-improvement content by developers for developers tends to be very negative like I can't explain it really well but to compare it to this sketch: https://www.youtube.com/watch?v=85HT4Om6JT4
Calling SWE "working in IT" is where it lost me.
IT the job is nowadays mostly understood to be about installing printers and setting up computers. Software Engineer/Developer/Programmer builds software. Sysadmins manage servers. SREs develop and operate production infrastructure. Nobody knows what DevOps is.
Outside of Germany and its neighbors, nobody thinks these four jobs are the same job.
Just like the debate about, "is it engineering"; by calling oneself as opposed to 'programmer', it conveys more prestige.
As a SWE, he sees himself in the driver seat of the company and doesn't want to be associated with being 'back-end', 'a cost-center', etc.
Nowadays, "IT" anywhere outside of Europe refers to basically an operational or support role. (I think Europe being the odd one out is an effect of most European business leaders still thinking computers are a fad that'll go away eventually.)
For reference, Merriam-Webster defines IT as follows:
> the technology involving the development, maintenance, and use of computer systems, software, and networks for the processing and distribution of data
Is this wrong? I mean, they do work in medicine. You can always be more specific if you want, but I don't see anything wrong with that statement.
> Being "in IT" typically means you set up office computers.
This is probably a thing that varies regionally. Here it is very common to call all the aforementioned jobs "the IT industry".
> You’ll need to work around incompetence
It’s amusing that the article never suggests you might be incompetent. No, no, it’s the “other person” whose incompetence needs to be well-documented.
> Rare work-life balance. In other professions, your work day ends at 18:00, and you forget about the job. Not here. You will most likely always be online and checking the code, even in the evening.
I’ve always tended to avoid this throughout my career, and my bosses and coworkers have always been made aware of that.
Wait. Would I be the incompetent the author is talking about?
And besides, it's not as if you're free of those things as a freelancer.
A dream house is another example of this. Let's face, housing is awful. The pie in the sky dream would dream of not needing housing at all, but more realistically I can also dream of a house that makes some things slightly less awful. Dreaming about that house provides me with information that I need to move towards it.
More likely it is a semantic thing. I imagine everyone does something like that, but may not call it dreaming.
We all like starting from scratch, from a clean slate, but that's actually the easy part, it only becomes hard later, when the requirement have changed and you start to notice the consequences of the bad choices you made earlier, and then you try to leave, or restart from scratch. So you want the easy part and leave the hard part to others...
But where is the fun in that? I went to programming because I like things like problem solving, and it is not problem solving if there is no problem. Digging into code that no one understands, that is not documented, working around limitations, finding what needs rewriting and what doesn't (with an emphasis on the "doesn't"), managing technical debt and deadlines without overworking yourself, etc... Now this is a challenge, this is interesting, this is the job I signed for even if I didn't realize at first.
And don't let anyone tell you that these are not coding skills. These are totally coding skills, where code reading is as important as code writing, where you have to be able to code with any API, in any environment, in any style. Not just the narrow subset of algorithms (which is also important).
However, the whole another universe uncovers if you remove "industry" concept that has been illegally attached to "software engineering" concept by Vadim.
In reality a lot of cool stuff has been built outside of corps, managers, offices, deadlines. The whole Internet works on Linux. Many successful games were built by folks who wasn't even once employed as software engineer. Some of them earned millions and billions.
Soft skills are never taught, rarely checked during interviews, but might well be themost important ones.
Actually this particular point reminds me of young-arrogant-me saying things like "I can't give you an estimate since its software, and everybody knows thats estimates are impossible, duh." to my boss.
Boy was I young, and arrogant!
Thankfully, I eventually came to realize that you can choose a random number. Nobody gives it another thought after you've answered.
This one I am truly struggling with, and probably will the rest of my life. Sadly it hinders the success of all of us as software developers. I'm currently reading "How to Win Friends and Influence People" by Dale Carnegie and loving it, but can't help but thinking in the back of my mind that somehow all these rules and guidance he has for being a decent human with other humans are extremely challenging when (in some cases) you are FORCED to work with said incompetant collegue. I agree entirely with the authors wording around this point, including "frustrating", "exhausting", and "toxic". Call me an asshole but I'm an engineer, by definition I like doing things efficiently and to the point. Working with someone who can't be either is incredibly challenging. Would love to hear more strategies people have developed to deal with this.
Reading comments here, I want to be clear: I'm not talking about some ego-based notion of "incompetance" like "I can write code better than you". I'm talking about the bigwig guy on your team with a big wallet who tells you the product should be implemented in XYZ because he read an artical about XYZ in a magazine and thought it was cool.
> Dealing with people is hard. Dealing with uncertainty is hard. Dealing with uncertain people is harder. And that's what you're going to do as a software developer.
Also this, haha. This post is gold. Nice work!
After covid crises, many seniors left, and I find myself being the more senior. There a few others seniors around me, but they have been on the same place all their life, so Im the senior with most different experiences.
I often propose/ask other teams to implement changes that I need. Is often challenging, the are contrary to change. Specially if it comes from somebody outside their current team. I follow this approach:
- I try to convince them, with diplomacy. Often what I request is also good for them.
- If they refuse some _internal_ changes I propose, I live with that. If that issue some day impact me, I will communicate with them by opening a ticket. If they dont work on the ticket, will be a project management problem, not an software engineer problem.
- I limit my interactions with them through their interface (ex: REST API provided by their service). On this point I'm rigorous, because the interface is difficult to change once is used by everybody.
In summary, if they have bad implementations or bad design, I try to contain inside a box. Some day a new guy will be able to solve those internal issues. But I trace a line on the interface they provide, and ask for an interface that make sense.
He's been right quite often, as I progress through my career.
Or the code is already ugly when you start touching it, your manager is assessing your performance based on features. Any time spend on refactoring is time you're no shipping features (worse, you may introduce new bugs). So you add your feature, making the code even uglier.
Or of course, the person who wrote the code was not very skilled.
there isn't a lot of value in clean code beyond making it easier to maintain. it can be argued that clean code over time makes code safer by way of improved maintainability (which is true), but 99% of the time, customers won't buy software because of how clean the internals are.
meaning: if a customer is willing to commit to purchasing your widget or your competitor's for $LOTSOFMONEY if a single feature is created for them, then you can bet your ass developers in both companies will author (be told to author) the shittiest version they can that works to win that customer.
think about the last thing you bought that you REALLY needed. did you care that it was a generic brand that looks crappier but gets the job done? same thing.
disclaimer: i am a huge believer in clean code and TDD.
I know this is kind of an unpopular opinion, but I think an important reason we end up with this kind of work environment is that we have no formal division of labor into separate professions.
Compare e.g. with healthcare: I sometimes jokingly explain the situation to friends by saying imagine if there was only a single profession called “Healthcare Worker”, and every hospital had to self organize “Hunger Games”-style. Everybody is hired as a “[Junior/Medior/Senior] Healthcare Worker” and then they battle it out to decide who gets to sit in the corner office, who gets to be a doctor and who gets to clean the toilets. Often it turns out everybody does a bit of everything, otherwise it’s perceived as “unfair”.
When there is no rigid formal power structure people make up for it with “politics”. I think that’s to a large extent what’s happening, and it’s sort of consuming our lives…
- we’re like a football team
- and that means it’s okay we have different roles that utilize our unique skills
- or because we need a single play caller
- but that doesn’t mean your role isn’t important; QBs can’t work with no linemen
- and managements job is to be high level direction, staffing, and play calling
- but they need to step back and let the people on the field do business
- and only bad managers don’t take feedback from the people on the field
You can give the same speech about military units or professional kitchens; because it turns out the ways humans organize aren’t all that varied.
I just wish we could get to a paradigm of “team building” instead of “fungible cogs in the process chart”. Both sides, employees and employers, would be happier.
Sadly I’m not so sure about that. If you’re mostly cleaning toilets in a hospital then you would benefit greatly from confusion about your role, so that you can have a bit of the compensation and recognition of a senior physician. In fact when there is a wide distribution of ability a clear majority benefits from this confusion.
I think the reason it works in football is that (almost) anybody can judge ability, so the confused state cannot be maintained for very long.
But sure, with exceptional leadership that will stick their neck out to “give credit where credit is due” you can get around this. It’s just very rare.
“Janitor” and “physician” are different kind of cogs.
What actually happens is that you don’t build the depth in your janitorial department that trades require — so the overall quality decreases.
“Janitor” and “physician” are different teams: they don’t “play the same sport”.
In software engineering, not so much. I think the OP illustrates that fairly well. What he’s describing is a janitorial job, but he clearly thinks he’s a physician, and he has written a blog post titled “What it’s actually like to practice medicine”.
This above line may sound arrogant because it sort of implies that you are the smartest of the lot. For all you know, you may be the incompetent one for someone else.
However, this attitude (without being a pr*ck about it) can be very useful in navigating your way through the messy reality and becoming more productive in spite of it. It will prevent (or reduce) a lot of "you should have said this before", or "I should have known this before", or "you cannot change that now", or "who wrote this code?" moments.
Hospitals are there to provide health care. But you'll sometimes hear a phrase in health that "a hospital bed built, is a bed filled" (https://en.m.wikipedia.org/wiki/Roemer%27s_law). Health organizations will push patients to get extra, often unneeded, treatments if they system has extra slack.
Similarly, management calendars always seem to fill. It doesn't seem to matter what the ratio of staff to management is, or what's going on at the moment.
In the short run. In the long run the lack of coding skills will start to show and bog things down. You need both domain and design in equal amounts for the long term success of a project.
Its a dream job for me and would be for 90%+ of my friends. I suspect anyone saying this has very little life experience. All jobs involve work (duh) but software pays very well, is in demand, only requires a bachelor's degree, and is very chill with a very good work-life balance.
If you're working unpaid overtime then get another job. I've only worked about 3 hours unpaid overtime in my 16+ year career. I've willing worked paid overtime a few times, but not often.
If software isn't close to a dream job then I'd like to know what is.
It depends. For hiring I would focus much more on coding skills than domain knowledge.
Reminds me of a company that was getting rid of the expert/developper communication bottleneck/gap by having domain people who code, and said it was much easier to teach the domain to a good developper (who should end up knowing it anyway, possibly in more details than experts themselves, due to formalizing it in actually executable code (requirements often don't even "compile")), than to teach coding to a domain expert.
Much of the audience and discussion here on HN revolves around applications in computing, the computer and data sciences, and software infrastructure. For this purpose, “external” business domain knowledge and value is of little interest?
Im not working a second im not being paid - its fun, sure, but its not that fun that i'll work for free.
I especially appreciate the aesthetic section as i constantly struggle to explain that concept to people on a line by line basis
No one ever gets promoted for removing features.
Any code base that has had a few birthdays has stuff that needs to be removed and might not ever get removed.
I’ve only seen this work in one company I’ve worked for and will carry those lessons with me.
Eh, what a predictable and boring attitude :/
This advice makes sense in a company environment, but there's so many other motivations to write code than just 'business value'.
And from what I've seen, focusing on 'business value' alone is the only explanation why so much software written in company settings is so user-hostile nowadays.
My counter-hot-take: focusing on business value makes you a worse programmer.
Those are all the same, the best programmers in the world (those in the demo scene) call themselves 'coders'. Calling yourself a 'software engineer' reeks of elitism, no matter how much time you spent at university.
For instance in Germany with its strong engineering tradition, nobody in their right mind would call somebody who builds software an 'engineer' (there are some google hits for "Softwareingeneur" but I bet this has a fairly recent thing and has been leaking back from English).
A person who builds software is simply called a 'programmer' or 'developer' here.
And I really have my doubts that there's any meaningful difference between what's called a 'software engineer' in the US and a 'programmer/developer' in Germany. Building software requires creativity, planning, experience, rationalism and problem solving abilities, all in the same person. If you don't have that, then don't call yourself a 'programmer' ;)
Out of interest what are the different skillset requirements between 'software engineering' and 'programming'? Because I really can't think of any.
You can look up "software engineer vs programmer".
15 years ago it would have been "Softwareentwickler" or "Programmierer" (optionally with the requirement of a degree in computer science, which - funny enough - also isn't excplicitely called a 'science' in Germany, but simply 'informatics'), even though the job description would be exactly the same as today.
If I have to pin it down, I’d say my degree had a lot of focus on all the phases of the SDLC, while computer science and programming are just one phase.
My course was an extra year and included mandatory classes on testing theory, large scale system design, real time systems, personal software process, and much more theory about the what, why and how of each phase of the SDLC.
My computer science friends were just writing code, without much education on the bigger picture.
So I would say a programmer is doing one piece of building a software system (like a bricklayer), while a software engineer keeps in mind and can actually perform all the tasks required to design, build, test, document and support the software (all the people required to build a building from conception to completion)
The way I see it, coding skills are necessary but not sufficient to claim the SE title.
If you take something away and no one will ever notice it has no business value. If people do notice, it has business value. Very simple right?
> Domain knowledge is more important than your coding skills
This is where I wholeheartedly agree with. As I'm tired of cargo cult, playing tools, solving puzzles for fuck sake. I pick a domain knowledge first when I want to learn a new language to see what I could write some useful (to many people) thing in it. Tldr; you as you go help the others, not just learning sake.
I WISHED in addition to Calculus and CS that some form of "effective communication course" was required up to 3rd year ! Even the "basics" like how to "Respond Vs React (the emotion)"
If you are a coder 90% of the time it's going to be a "social" or "team" activity. And where you find people you find people problems, egos, miscommunications, anger etc !
The amount of time you will have the debate about "how to code something the 'correct' way" will be the cornerstone of your success in a team. That 'debate' about the 'correct way' is hard since CS is such a young "engineering discipline" compared to say how to build a bridge.
I can tell you this, the other coders I worked by far the best with are the coders that can communicate or that I feel 'safe enough/trust enough' to talk honestly and openly and separating yourself from your code ("you-are-not-your-code") becomes automatic with these types of pro-communication programmers.
TL;DR: If you want to be an effective or standout coder: Focus HEAVILY on your communication skill.
1) In the long run, benefit accrues to value generation. The "best developer" turning out "amazing code" that misses the business goal is generating zero value. It's a hard fact to swallow.
Ideally you are someone who can both engineer good code and be at least a part of the brain trust that "aims" that code at value (solving biz problems and generating money.)
That sounds obvious but most people don't even think about that. My rule of thumb is that unless you are actively involved in that - ie acting as a product manager to some extent - you are likely under-delivering for yourself.
2) your biggest limitations are within yourself and you don't acknowledge them. That's the classic "I identify as X and therefore don't do Y" mindset, where Y is the thing that would "unlock" your next level. Like if you are "a C++ developer who isn't interested in talking to customers" then perversely, learning how to talk to customers (and not learning the next C++ standard) is the thing that will let you double your comp.
3) Your attitude determines your outcomes. People who assume all work situations are shit (assuming that bosses are always evil, coworkers are always stupid, etc) end up in precisely those situations. If you have a more positive expectation (eg want to give and receive loyalty, want the company to go above and beyond for you and to go above and beyond for the company) you can find those work relationships too. (Btw that applies outside work as well. If you believe all women are evil you end up an incel, etc)
4) Work is a team thing, and the people matter. How you are with people matters too. Whether people are looking forward to or dread meeting with you has a huge impact on your productivity and therefore your career. Also, there's a Darwinian element you should recognize. If your team succeeds, your colleagues get bonuses and grow and that should matter to you, not just whether that happens to yourself.
5) You get paid for impact in the long run. This is related to point number 1. Sometimes your impact isn't code but persuasion. I once convinced a company to shut down a line of business and focus on other things. The value of that is much greater than any code I wrote. To make such impact you need to (a) have original perspective/insight and (b) convey it to people who don't have that insight! If you are constantly frustrated because you are misunderstood, you need to make a conscious effort to learn how to persuade people in person and in writing. And to recognize that it's a slow and difficult process that most people fear and therefore fail to go the distance.
6) The concept of work life balance is misleading and too simple a frame for good outcomes. The homeless guy under a bridge has a great work-life balance (0 work) but his life sucks. On the flip side, some successful people work tons of hours and have a great life - because they enjoy their work and they enjoy the financial benefits.
Domain understanding is just understanding, it's not related to HOW you do it effectively.