> The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)
I agree but think it is more than just _documentation_: effectively communicating ideas through text was one of the most underrated skills in software engineering. I say "was" as I think there is much more focus on it now with remote work and video call fatigue becoming the norm for many.
That's useful, but only covers documenting the code, and API usage.
Depending on the project, various other documents may be required, e.g. installation guide, user guide, operations manual, architecture diagrams, networking diagrams, module/component diagrams, information flow diagrams, high-level design, low-level design, docs at various "views" (such as "business view", "information view", "technology view"), design decision tracker, ontology...
I'm actually in the middle of using Postman to generate a more "modern" inline docset for a new engineer that is coming into a project that uses that server.
I would suggest you avoid thinking in too general of terms like this. There are dozens of kinds of docs. It's better to think about the document's specific purpose, audience, what you need to convey, what the audience wants to know, and how they want to absorb it. Then write, then read it as that intended audience, see if that person can make sense of it, and if it provides enough information. If you can't put yourself in their shoes, have the audience proofread it.
Two important lessons I learned:
1. Formatting and direct communication is very useful. It can make the difference between someone stopping and noticing critical information, or skipping it because they're lazy readers.
2. You probably don't know the correct way to convey information, and the audience probably doesn't know how to tell you how to convey it either. You need to listen for when the docs fail: when somebody says they read the docs but still don't know something or don't do something right. That means your doc has a "bug" in how it gets through to the reader. Experiment, change things around, add/remove information, etc until the bug is gone.
Agree with the sibling comment, but a starting point is also just to write docs for your future self, which is usually going to be type 3 or 4. Most of us who have been programming for a few years have had the experience of being mystified by something we ourselves wrote in the past, so it eventually becomes fairly straightforward to predict what kinds of things future-me will need a hand in piecing back together.
And it turns out those kinds of docs are pretty useful to my colleagues in piecing it together also.
In contrast to the current sibling replies, I think this is a very fitting categorization of documentation. Off the top of my head, I can think of several examples where one type of documentation is excellent but others are very lacking, for example:
* Rust Library Documentation: Most libraries have complete and up-to-date reference documentation, but are lacking even basic introductions (tutorials/guides) on how to use the library. This is totally just my personal experience so maybe I've been looking at the wrong crates, but with most of the crates I spend several minutes looking trough all the modules in order to find that all the juicy functions are hidden in the Connection struct, or something similar.
* Linux Kernel Documentation: The Linux kernel has excellent in-depth explanations on several high-level concepts, but on the other hand a little more systematic reference documentation on the supporting library code would help a lot.
* While I can't think of a good example right now, a lot of projects have a few basic getting-started tutorials but don't explain advanced concepts or high-level design at all, leaving you to wade through the sources yourself in order to understand how to actually use them.
Also "if the code is clear, it documents itself". Which in my opinion completely misses the point. Good documentation doesn't tell you what the code is doing, it tells you why it's not doing something else.
We had a guy that always opened PRs with no description. Guy always said “read the code”. Manager wouldn’t do shit and he kept doing it until we all just stopped reviewing his code and then he couldn’t merge.
Like dude, tell us why we should read the code in the first place.
One can hope, but sadly I don't think it's going to be an easy shift.
People managing work, from what I've seen, still prefer to babble over their scribbled 5 basic points than taking the time to do their job and create relevant textual information. Then you listen, you take notes, and then you go and produce whatever documentation of the objective is required to at least understand if it's going to work. Of course you still will have gaps in your understanding, so then more calls, and repeat. In the end, unnecessary/missing features, a whole bunch of time wasted in crap, deadlines missed, burnt time, all of which could have been avoided if someone just had taken the time to do their supposed job - this is not to say it wouldn't have to be discussed, or that there's no need for back and forth and calls, etc, it's just instead of starting halfway you start from -50% or something.
Even in outsourcing platforms there's been a shift contrary to that. At least two years ago and before that, video calls or calls weren't really usual unless you were in some months long collaboration - now even there everyone expects video calls on the interview... It doesn't matter if it's a $100 one time job or whatever.
Effectively communicating through text amplified due to WFH. If you can avoid syncing up on video chat and resolve something with a couple of back and forth messages. That's a win
I end up reading the source half the time, anyway; documentation is often incomplete, dated, and possibly incorrect. For code, I'd prefer the time go into designing a cleaner interface and making what calls do obvious.
That said, I find high-level documentation for larger systems to be very valuable. I also find Python's docs to be lacking compared to Java's; I'm often left wondering about the definition of what type is returned, exactly what parameters should be, and which exceptions are raised. Java's docs are very explicit about all these things.
Thoroughly commented code tends to end up a couple changes out of date. A separate file in the same directory ends up a couple major refactors out of date. A separate file in a separate system ends up a couple company-wide reorgs out of date.
You should be reading the source all of the time. The point of documentation is to tell you what the code doesn't. If it tells you the same, you should delete the documentation.
I agree. I'd like my documents to contain overview, intent, and exceptions. The actual implementation I can look up in the code. Also generated stuff is appreciated, like Swagger.
> effectively communicating ideas through text was one of the most underrated skills in software engineering
Absolutely. So many hour long meetings could be shortened by better communication skills (just more targeted), or even a small email chain.
Communicating in short form confidently is a skill. Many people, including myself (something I've been working on) struggle with saying something that was a complete idea in a meeting and not stopping because they feel like they need to say more. Short and sweet is the way to go pretty much whenever you can, for technical work that is.
And many many people don't do it well. On both ends. Reading is a skill too.
I find 'small email chains' don't help at all. Too many people just don't read past the first sentence or paragraph. And email is slow.
I usually 'escalate' quickly. Support didn't understand a ticket comment I made on how this isn't a bug or why there really is a workaround for it?
I send them an IM trying to coax it out of them/get them to understand for a few minutes. Doesn't work? Quick call and do screen sharing. Problem usually solved after a few minutes. Problem is they might stay longer than that took just to 'catch up' ;)
This is really not that different from when we were all at the office just that the last part would be walking over to their office and looking at the computer together. In some situations that makes it even easier nowadays because I don't need to take an elevator down 20 stories and back up again after.
Having asynchronous means of communication is great. But as soon as the back and forth is more than maybe twice on each side, there's probably a miscommunication happening somehow that will be much easier to get solved with a really short feedback loop. Some people you have to call right away coz they just type soooooo slowly ;)
I find documentation to be relatively straightforward to write. The issue for me is sitting down and slogging through the activity, which seems almost antithetical to writing code. It's like doubling the work in a far less rewarding way. And then you have to go back and update it any time the code changes. It's a sort of necessary evil I suppose...I think most of the problem is that devs just can't be fucked to take the time, and I'm often guilty.
Documentation can also be anything. Is it your initial RFC or ADR, or is it a spec? Is it a set of product requirements? Is it inline with your code so it produces a manual when you build it? Is it a set of articles or tutorials written after the fact? Is it a README?
Exactly. That's not a documentation problem, that's a writing problem. A lot of tech people don't enjoy writing, but also they're sometimes not very good at predicting or empathizing with the future reader of their writing. Sometimes that's also manifested in speaking, and failing to context frame concepts, arguments and ideas before jumping into excruciating detail. Senior managers notice this, and this limits your career.
So I argue that the issue is writing skills, of which technical documentation is a subset speciality of writing skills. I will add, similar to math problems or programming, writing wants you to do it over and over so it can get better.
> A lot of tech people don't enjoy writing, but also they're sometimes not very good at predicting or empathizing with the future reader of their writing.
Agreed, wholeheartedly. Will hitchhike on your comment to recommend two things: Brett Victor's pdf stash [1] and, specifically, the Walter Ong essay "The Writer's Audience is Always a Fiction"[2].
Long story short, we form our audiences by subjecting them to our writing. In writing software documentation, we are implicitly informing the next generation's thought by the simple power dynamic that underlies all technical documentation: "you must understand this in order to do your job properly".
It is no wonder that "form", "inform", and "information" are such closely related words.
We dictate the level of rigor and intelligibility we expect out of our technical documentation, when we write technical documents. It almost sounds like a tautology when put this way, but "bad docs" are exclusively the result of a professional culture that puts up with the existence of bad docs. I've been there; too tired and overworked to care about writing something properly, or wanting to avoid writing a doc enough that I setup some autodoc thing and called it a day. We literally don't get paid for writing documentation.
But good documentation is what made us into good developers (if we are good developers). We should get paid for doing that...
Effective communicating is a crucial part of every job. I think in software engineering, a lot of us are introverts who want to deprioritize this soft skill, but the truth is still that people matter more than the code.
And communicating gets even more important the higher up you move in your seniority.
Not only in writing but also in plain English.
I see situations like described below over and over.
Example 1 - too much details.
Morning stand up.
Manager: what's the status of that new feature.
Senior Engineer: well I tried to call that service but it was timing out so I spoke to Bob and he said to check with DBA on why that stored procedure but it's so slow and turns out index is missing so we tried to add it but mysql and varchar something fckn something...
Dude couldn't you just tell it's delayed due to DB and then expand if needed.
Example 2 - insufficient details
I return from the meeting and discover avalanche of emails, chat messages and urgent meeting invite, all with same topic - "Blah service fails, we are blocked" but no details apart from that. On the call I get description of the problem - blah service fails and how everyone is blocked and how infinitely critical it is and what ETA for resolution would be.
What endpoint? How does it fail - timeout, connection aborted, 503 response, 200 response but with error message?
I like documentation that starts with a minimal but functional example, followed by the most common additions to improve the solution and finally a complete documentation of all functions.
Having links to actual code, like GoDocs have it, is something I appreciate too.
> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all.
This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.
Someone please translate that to Latin and start plastering that on office walls so people take it more seriously. It’s going to save all of our mental health in the long run.
It's been seven years since I've tried writing any Latin, so you should assume this is butchered. (edit: I think it's less butchered now)
codex bonus a discipulo prendatur
codex magnus a novo prendatur
codex optimus nullus est
Part of the problem is I couldn't find any good word for "code". "Codex" sounds cool but may not be the best fit here.
EDIT: Forgot a word. Also, I think "prendere" is better for "understood" here than "scire", which is more like "to know".
EDIT2: My friend suggested using the subjunctive for "comprehend" so that it's "may be comprehended" instead of "is comprehended". Also I got the tense wrong initially and I think that's fixed now.
EDIT3: "Ablative agents" are a thing. This is a rough language. Thanks, James.
EDIT4: prendar -> prendatur; aka "oops, should have used third person"
That's a good find, but I was unsure of whether "program" is semantically equivalent to "code" here. Plus I'm tempted to leave codex since it sounds so good.
Amen. Something bizarre I have noticed though in junior-almost-senior engineers is that they pride themselves in obfuscating and writing "highly complex" logic, with no documentation. It's almost like they are demonstrating their new abilities in the worst way possible. I have been dealing with one of these engineers recently, and they have expressed to me that they love writing <highly problematic, confusing code> because it's so terse. It's been a point of friction, actually, because I have been trying to get other engineers to help on the software they have been contributing to, but it is nearly indecipherable without the original author's help.
I wish more managers and business stakeholders investigated this more carefully. Team members of this type add a shadow overhead that impacts velocity dramatically. It’s always visible to average competent devs on the team, but can be invisible to managers who don’t investigate as to why only one person is particularly productive on the team. Most people won’t go to their bosses and say ‘so and so writes overly complicated code that’s making my life a living hell’.
In fact, I think a third-party auditor would be a valuable service for dev teams to utilize at least once a year. Totally neutral party that can come in and say ‘We’re pretty sure the codebase is too complex and we noticed the commits came from so and so’. The business value here is you can root-cause velocity issues that can come from decent people who need to be reigned in (not necessarily fired).
I’m literally prepared to pay to have these people objectively assessed.
I would do this auditing job, no joke. A kind of "code-smell" service, that can yield problematic areas, along with a report of engineers that could use additional guidance/training/reigning-in would be super valuable from a manager's perspective. And because it's a neutral party, they can feel good that there's no politics.
One challenging bit about this service would definitely be quantifying improvements. Since the problem is somewhat hidden by nature, you would almost need testimonials from other engineers on the team.
Another way to remove finger-pointing is to identify features that should be reasonably easy to implement, but for whatever reason don’t get done in time, or worse, don’t get done well (end results being bad).
If a team was tasked to make a simple landing page for example, and it was oddly hard or time consuming for an average team member, it would be good to dig into why. If the answer is ‘you should see the boilerplate involved, or the deploy process ...’, then you can make a neutral analysis as to the cause.
Testimonials aren't a bad thing though. I think every dev should have their code read and evaluated by at least one other person, although getting as many people as possible to read it would be best. If code legibility to help team members understand, debug, and improve upon the code is essential, the best metric to use for code quality would be their collective feedback on said code.
> Totally neutral party that can come in and say ‘We’re pretty sure the codebase is too complex and we noticed the commits came from so and so’.
This sounds like it'd reduce psychological safety on the team, to have someone without the project context come in and criticize your engineers. The morale decline of such a choice could outweigh the benefits.
It’s a suggestion. Generally, code complexity is created by someone that is actually pretty knowledgeable and competent. A straight confrontation won’t easily neutralize such a person in a discussion. They will know how to defend. If they also have peers they are close with, those friends will also negligently condone it with a simple ‘I don’t see anything wrong with that implementation’.
It’s a tough one, so I don’t even know where to begin other than an independent arbiter. Anyhow, I agree with you that it is a delicate matter from an emotional perspective (even though the underlying can be a reasonably objective matter).
That hurt me to read! Have you communicated this to your manager? Might be worthwhile to have a decision "from the top" that is essentially: all logging is good, so long as it doesn't hurt performance or contain PII/PHI.
three things i find to be true of every web app i work on:
1. good logging is the most important part of the app. whatever the app is meant to do is secondary. the app should be a logging app first, and then a backend service to sell widgets second.
2. assume performance requirements for request latency and transactions per second will be at least 3x whatever the product owner tells you at the start of the project and plan accordingly. never trust any suggestion that you can 'ignore performance for now'.
Boundaries between anything. I recently was dealing with an issue in a Jenkins pipeline, where I didn't realise that state was being serialized to string form between job stages until I explicitly logged it out. The thing that was a list in the previous stage was suddenly a string, but then Groovy would happily accept the join method on a string because it's still an iterable. Auuugh.
> Something bizarre I have noticed though in junior-almost-senior engineers is that they pride themselves in obfuscating and writing "highly complex" logic
I think it happens because most measures of code quality are quite fuzzy, but brevity (which is valuable, other things being equal) is relatively objective. "Have I made the code shorter?" is a much easier question to answer than "Have I made the code easier to understand, modify and maintain?"
I think another place people can end up here is if they don't know what the compiler is doing under the hood, it's easy to assume the shortest code will perform the fastest or something like that. "Presumably this cool trick avoids these extra steps" type of things.
Before I had written much assembly, I used to think ifs to avoid assignments was smart. Turns out avoiding branching is better for both testability and performance.
A similar thing I've noticed a trend of recently in frontend react codebases is overuse of memoization. It seems as though people don't realize how it works and that it is often _less_ performant than just doing some low cost computation on each render (like a comparison or basic math).
> "Have I made the code shorter?" is a much easier question to answer than "Have I made the code easier to understand, modify and maintain?"
This is something that comes with experience though, and I think a lot of people don't truly grok this until they are trying to maintain their own terse/clever code written months/years earlier. Nothing is quite as humbling as doing `git blame` on some crappy code only to see your own name there.
The same goes for junior writers who think that complex sentences and words are a sign of superiority, and later discover that the real (and bigger) challenge is writing clearly.
Along the same lines, I recently reviewed a junior engineer's design document and pointed out to them a diagram showing the actors, their roles and interactions would have saved two pages of dense, complex text, and made the solution clearer.
Amen to that too. That's probably the most complicated part of being a manager or tech lead. You have those amazing junior-almost-senior engineers that could be way more productive and yet deliver better code, purely by "doing less", but the over-engineering gets in the way. You know they could be top-contributors, so you don't want them to leave. But at the same time it's very tiring!
I noticed that they put a lot of their self-worth in the sophistication of their code, so it's difficult to criticise without making them feel bad. You need alternative methods of getting them to "see the light" and write code that's more understandable and maintainable by others.
What alternative methods have you found to get them to "see the light"? I've found myself wishing they'd do therapy, but that doesn't help and can't be expressed.
Mostly public feedback (for only the good things, of course). Put their "good" code on code samples, documentation, code guidelines, tell the team "look everyone please do it like person X did here". It will surprise them in a positive way.
Also on PRs try to point to their own work as sample of how to do things better. This doesn't hurt the ego much, because the role model is themselves.
Also, I feel like most of the time this is an impostor-syndrome/perfectionism issue that also happens with other workers too, so HR can give tips on how to deal with those issues in a more sensible way and tell you what you can or can't say.
> Something bizarre I have noticed though in junior-almost-senior engineers is that they pride themselves in obfuscating and writing "highly complex" logic, with no documentation
I've noticed this too. One thing I've had mild success with is the concept that a particular programming document (especially in functional programming) is really a series of mini-documents. Each mini-document has function-level comments, a signature, body, and returns that tell part of the story of what that function does. The minute that the collective of those fail me and I find myself reverse engineering code, then we have failed the team and cost the company money.
Some complicated things must be done, especially at the size and scale of our products, but complex things are painted with a fine veneer of interfaces and documentation.
I think another exercise that can help is putting junior engineers front and center to architecture. Whether it's exposing them to review, the review process of a Senior engineers design, or putting them front and center to design implications. I've seen having to figure out the difference between a controller and a service cause some really positive abstract thinking that puts people on the order of thinking for the group rather than their own merits.
I worked with a guy very much in that vein. He had enough years of experience to call himself senior, but it was clear his actual skill level was halfway between junior and senior at best. He wrote the most clever, fancy, opinionated code I've seen in a while, and he wrote a lot of it. I weep for the programmers that will come along in a year or so that have to figure it out.
I think there's an element of pridefulness too, in having the ability to manage dense and intricate stuff at all. They're very smart, and it makes them feel good to be able exercise that and juggle and retain so much context at once. And they don't realize how fragile that juggling is, that it's going to take a ton of effort for them or other people to come back to it.
I think this is more prevalent for some languages/stacks than others, too; there's definitely a cultural aspect fostered the language owners or whoever the leaders are.
Does that matter. A team with a senior/junior separation should have in place a system of peer review where a code not understandable to a peer will not get merged upstream. There would be a CI system with a linter that forbids abusing syntax for writing dense/obscure code. If a code requires documentation there should be in place a doc-coverage tool which forbids new undocumented code from being merged upstream.
If these systems are not in place, and a senior developer can get away with writing overly complex code, then that is the fault of management, not the developer.
Absolutely, you need to care for that future dev who's an idiot when writing code today because that's going to be you in a week or two when you've forgotten all about it.
This sentiment is exactly why programming in an org-chart is so much different than programming as an individual.
Don't apply corporate best practice designed to withstand turnover to personal programming - you're leaving abstraction and efficiency on the table.
The better code for your own projects is almost definitely inscrutable to a newcomer a lot of the time. It's okay for there to be prerequisites to understanding.
I agree with this in principle but in practice code I write that’s quick & easy and not very readable is usually not understandable by me in a few months either. So if it’s a personal project I hope to last I still want to keep it simple with my code.
I'm not saying to hack away and make a mess necessarily.
Sometimes the simplest solution also requires learning and building upon other concepts. Or sometimes, a simple interface is written around a complicated core.
For example: The OP's quote is used time and time again to argue against FP concepts in industry - a newcomer doesn't know the first principles, so by the OP's folksy razor[1], that code isn't as good as less abstract code that doesn't require learning a new concept or two once and for all.
[1] Folksy razors are the essence of every principle-ish-level engineer's methodology I've run into. Corporations value the ability to remove all human agency & decision-making from software development where possible.
> Corporations value the ability to remove all human agency & decision-making from software development where possible.
Corporations value the ability to continue as an operating entity and make changes to the code after the proponent of Kleisli arrows and lenses has departed for greener pastures.
Doesn't mean I have to respect for be sympathetic to it. It is just organized stupidity at scale.
That said, it's hard not to play the game and buy in. I just write my vanilla Java, say right-sounding things in meetings, and somehow get Paid despite barely doing a thing.
Corporate software development is a great career tbh - instead of paying me to use Kleisli arrows for the company's gain, the company effectively pays me to use Kleisli arrows on my own IP lmao. Gotta love all that frothy waste that's produced by Worse is Better. Waste that the average dev can now reap thanks to the boom in remote work!
I’m not sure, you can become the newcomer yourself when you have to come back to parts of your code base months later. My experience writing simpler code has been pretty successful to respond to customers wanting random new features.
It goes too far though. The virtue of simplicity needs to be balanced against the virtue of making proper use of advanced language features.
A first-year student is unlikely to understand C++ template metaprogramming, or just about any Haskell code, but that's not to say they should always be avoided in production code.
> The best code is no code at all
This can be interpreted as advice to avoid the 'inner-platform effect' anti-pattern. Good advice, but personally I'd rather express it in terms of the inner-platform effect.
IME good commenting alleviates a lot of the “problems” with using complex language features. I’m thinking redis style comments (see here[0] for antirez’s philosophy on the issue). If you’re doing something that’s not immediately obvious, explain what you’re doing! That way others can verify it during review, and when someone is reading the code later they can read the comment to understand what’s happening rather than having to parse the code. IMO this applies just as much to simple constructs as to complex ones. Big for loop? Throw a comment at the top telling me what it does so I don’t have to read it when I’m skimming later. Better yet use `map` with a well-named function. Either way, provide a semantically meaningful summary of what’s happening.
> If you’re doing something that’s not immediately obvious, explain what you’re doing!
Agreed. Comments have their place, and some code is unavoidably involved, just by the nature of unavoidable complexity. The solution isn't always to write simple code. If it were, we wouldn't bother studying clever and efficient algorithms.
Also, it's important to ensure comments are updated when code is changed. I don't know who originally said it: Stale and inaccurate comments are no longer comments, they're lies.
That blog post looks worth reading properly, I admit so far I've only skimmed it.
> A first-year student is unlikely to understand C++ template metaprogramming, or just about any Haskell code, but that's not to say they should always be avoided in production code.
They're just the people to read a book on the topic and try to use it everywhere...
I agree with having empathy for future devs, but I think it only goes so far. I've often seen junior engineers unable to differentiate between code they don't understand and bad code.
Usually they end up thinking they can do a better job, decide to rewrite the thing from scratch, and take 10x longer to rewrite it than they thought it would take. And accomplish nothing in the end, because the thing they rewrote worked in the first place.
I disagree strongly with it on multiple fronts. That concern should be secondary to your program actually doing its job well. Your customer will literally not care how elegant or ugly your code is; they just see the end result. And when the program fails them, it really doesn't matter to them whether your juniors understand the code or the error. Moreover, not every abstraction is (or can be expected to be) accessible to an entry level engineer. Some technologies just take a long time to master, and doing that can also require higher-level abstractions.
So I would say great code is code that:
1. Does its job well (robustly, performantly, etc. in whatever proportion is applicable)
2. Is maintainable by engineers with reasonable expertise in the tooling
in that order. If you can manage all that and make it accessible to your junior devs, that will of course make your code greater. But don't lose sight of what your customers care about. Your business isn't there to make you feel good about maintaining code, it's to provide customers with value.
How many entry level engineers come onto a project per year? 5? Is onboarding them onto the project is a deliberate and streamlined way such an undue burden that you must change your programming style to avoid it?
This assumes you are absolutely certain you know what the code should do. And that it does what you think it does. Hence while you might think “performs its task” is an easily defined I’d disagree. I’d take clear code that wasn’t working over code that was hard to reason about and somehow worked every day.
No because I’d fix the easy to fix code, and make it work correctly. The other code is useful for sure. I mean people have built billion dollar businesses on crap software that barely works. And very rarely do they manage to fix them... I’m just suggesting I have a preference for what I’d rather work on. You might like code that works and is impossible to understand and sits there surrounded by an even more obtuse test suite (if at all), but it’s not something I enjoy is what I was saying. To some degree this is inevitable but I think it’s always worth trying to fight the good fight.
Most likely the code I write has a bug in it. Or, at the time of writing, the customer requirement is fuzzy. Or, I have a limited grasp of the problem domain. Even if it is not any of the above, most likely there will be a change in a business requirement that impacts the code.
So whenever possible, I opt to write code that is either stupidly obvious, trivially testable, or easily replaceable.
It depends on what you're optimizing for. I like to think of it this way. A good "programmer" can take ideas and turn them into working software that is performant enough, meets all of the requirements, etc. This is a mostly static operation. A good "engineer" can take ideas and turn them into working software that can be changed, updated, and maintained for years to decades by multiple programmers.
There are code bases at my current employer that are entirely "ok" and still being worked on from before I was able to spell my name. Projects that have had continued development for >20 years by armies of engineers and the code is still readable and simple to understand.
I strongly disagree. You're packing a bunch of different metrics of quality into a single bullet and somehow suggesting those are separate than the second bullet point. Readability is just as dependent a metric as the others. If you make things that are hard to read, I can guarantee they are not going to be robust, as well as likely not performant.
In my experience, the easiest to maintain code is very often the most efficient and robust as well, because people haven't felt the need to hack around it at every corner.
It really does matter to the customer if the junior understands it when the code fails though.
Easy to understand code can be more quickly patched and repaired by anyone on the team. If you don't need to call in the senior who built it two years ago to repair it, and you can have someone do it right away, it is better for the customer.
I never said it doesn't matter. I said it matters. What I'm saying is the scenario you're portraying literally cannot play out pretty much by definition (and also empirically, from what I've seen) unless you accept that code readability for juniors is secondary to program quality. When you make readability your primary concern, it comes at the cost of fixing certain bugs and design issues... precisely because the best solutions may not t be trivial or easy to understand by the junior folks 100% of the time. So you never get into your purported state where everything was well designed and implemented in the first place and now you have to worry about getting a junior to fix a bug. Everything ends up clunky from the get-go and you never get a high-quality, robust program at all. Just something of mediocre quality with a ton of patches from devs of all level to get something like 85% working, shipping with know issues you could've avoided if you hadn't artificially restricted yourself and tied your hands behind your back for the sake of the juniors.
As with all software engineering, it’s all about trade offs and context.
That performant code that you wrote maybe at the expense of readability? It could very well become bad code when you leave the company and it falls to a junior engineer to modify it to fit some changing business requirement. Or, there’s a bug in the code and the amount of time it takes to fix it is a direct function of how quickly and completely that junior engineer can understand the code.
For me, the hard part is knowing when and how to make that trade off. I’ve definitely erred on both sides often enough.
But, I do not know if this metric is quite 'complete'. Because, I am very sure, wrapping concepts in mind is more difficult than understanding the code.
I am not saying the code cannot be made better or more clear. But, it also depends on who you are writing to. Somebody who is not familiar with certain style of programming cannot easily read the code of certain level of complexity.
When I was hacking away my first big program, I could not write functions. Or find reading functions easy. The whole thing was a big wall of glorified assembly sewn together by labels. I am not sure why I was like that then, but I found concepts 'functions' and recursion or any other conceptual stuff really hard. My code was, in its own twisted way, 'most simple' and utterly unreadable.
I find the same sort of difficulties while reading some FP snippets. I confess it was a very short affair, but I had some difficulty reading it and even when I understood, I could not just write or think code in the same style.
There are ways to make your code better, your intentions clear but 'can be understood by a first year CS freshman' is bit abstract criterion.
It is kind of like, vocabulary and prose. You can make your prose clear. But, people have to work on the vocabulary on their own.
> The best code is no code at all.
This is completely agreeable.
Edit : Changed some poor word choices. Added an analogy.
I think of it as writing code for the computer/compiler, rather than for human readers. If the computer "understands" the code, you think you're done.
I real life working on a team with ever changing code, that is the barest rank minimum.
As a young programmer, I thought I was a master when I got the code to work. Now I know that is just the start. Making it readable and changeable is where real mastery lies.
This is very hard to convey to young fools as I used to be.
I've been fighting this at my company lately. We have a CDF that _clearly_ rewards people who write really advanced Ruby code. We have a lot of working, but not perfectly architected code that people come back through, pull it out into a module, and add a bunch of "included" and meta-programming.
It works. I look at their code and think "that's neat", but you added 0 functionality while making it hard for the lowest half of the engineers to work with. You could have accomplished the same thing with hard-reference to a class.
Thats what I've noticed with TDD advocates - the amount of code required is enormous and distracts from the flow of control. Everything replaced with mocks and stubs and there's objects replaced with instances from global scope, not very good.
> I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.
AMEN to this. I've been in the industry for 20+ years and at this point I know so many different frameworks (front-end and back-end), databases (SQL and NoSQL), networking protocols, browser differences, ORMs, it goes on and on.
I think people in the industry are paid based on the potential value they can create (whether real or not), knowing many things or understanding fancy technologies matters little if one can't put them to use for the benefit of the company.
Also, most companies like to brand themselves as ‘tech’ to signal that they are growth based. Why is Peloton a tech company? They’re not.
A lot of us have jobs because companies need to fulfill the image. It’s half the reason why so many people are allowed to do full-stack when in reality they would have no business dealing with those parts of the stack in a real operation.
So no, you don’t actually deserve more money because you are working on more things in an inconsequential space (e.g What the entire Peloton engineering team does is probably bullshit. You need maybe a few devs).
There are certainly better examples than Peloton, but that’s what came to mind (a home gym tech (lol) company). Can’t wait until Bowflex starts hiring out web developers.
I've helped found multi-million dollar companies that I left before I could "cash out" because they were desktop based companies working with technology I considered growing stale and I wanted to switch to the web.
Now I'm doing the same thing with another company with the web, expect I'm handling everything as a sole-engineer, full stack.
Here I'm dealing with creating an Angular application to replace an aging ASP.Net MVC app, having to rewrite hundreds of SOAP services into a proper REST architecture, and dealing with an Oracle database who's schema we need to keep in place. With a C# .Net Core back-end.
This company needs me, badly, but I doubt this is going to be come a cash cow either (no equity, just a paycheck, and their budget is tight).
It seems to like you are refactoring an existing application, I'm personally in the middle of something similar but rather than doing it solo, I'm trying to engage other Dev's, grab their interests by demoing the new architecture and see if I can get a few more hands on this work.
I'm doing all of this extra work because I think the best way to create value for a company is to make it easy for other/new developers to jump in to the project and contribute something of value quickly.
My refactoring would have failed completely if other Dev's are not able to contribute the new code
> It seems to like you are refactoring an existing application, I'm personally in the middle of something similar but rather than doing it solo, I'm trying to engage other Dev's, grab their interests by demoing the new architecture and see if I can get a few more hands on this work.
The problem is they literally can't afford it. They looked at "near shoring" companies but they were too expensive. They said we got a quote for developers from another country who will do this work for $20/hour.
I explained that this has the potential of ruining a green-field project that absolutely needs to be architected and coded properly from the ground-up.
If we go that route the best I can do is enforce code standards and handle every pull-request.
Could you expand on why you seem to think (if I’ve interpreted your words correctly), that a project is potentially doomed if the programmers aren’t from your country? That sounds awfully prejudicial to me.
I've never seen so many job opportunities in my life. Getting what you want out of employment right now should be as easy as filling up on vitamin D; just walk out the door.
These days you can hire from around the globe, instead of looking at off shoring companies, just look to hire a few talented people directly. Theres no reason a company can't afford to hire a few people remotely. Basically create a small team that is focused and invest in them.
Enforcing code standards and reviewing pull requests is a suitable role for a senior engineer. Not all things need to be architected, there's ton of glue stuff and features that can be developed by juniors provided the code around them is laid out nicely. Focus on the bigger picture, if u implement every little detail, then it starts to feel like everything is so important that it can only be done by you. That's a trap.
From my experience this is true because the team is so focused on getting the backend business logic sorted out, catering to new customer demands, that they develop new features overnight.
Then just assume the front-end will consume it and output a little, inconsequential DOM element here or there.
I see where you're coming from, I do all that too. But it's the "jack of all trades" thing. You "know" all that, but do you actually __know__ all that.
I can develop a nice relational database design, write the SQL stored procedures to manipulate it, write a backend API and write the front end SPA for it. I don't think I'm an expert in any of those things though, and if I am then it's more focused on the backend API stuff.
Like, I understand CSS better than most people, but I'm not a guru like some. I can write SQL for anything I need but I couldn't tell you anything about performance tuning my SQL outside of seeks vs scans and the size of a lock.
Understanding the basics of these things isn't really a daunting task and that's why full stack devs aren't paid half a mil a year. But you have to accept at some point that if you're full stack then you're rarely going to be considered an expert in any field. That's not bad though having rounded knowledge is super good.
>You "know" all that, but do you actually __know__ all that.
Companies that underpay fullstack web developers usually don't actually care if their engineers __know__ all that, either. They just want the cheapest, fastest, CRUD app they can demo and ship out ASAP. As a result, these employers fail to recognize (and reward!) the fullstack web developers who do actually __know__ the full stack.
At my last job there was a rockstar web developer engineer who could easily double their compensation by moving to a larger company instead of a startup. My advocacy for them to get a raise or promotion was cast as 'the engineer is complaining again."
The issue is in actually using all that knowledge in a single position and creating enough value. Larger organizations have specialized teams that move faster at their function rather than generalized devs.
The way for full-stack devs to profit most is to work at smaller companies and trade that for equity and seniority.
Probably people are honest when they are drunk. There is nothing to argue with any of those comments.
But this one stood out for me!
> Titles mostly don't matter. Principal Distinguished Staff Lead Engineer from Whatever Company, whatever. What did you do and what did you accomplish. That's all people care about.
That's true unless you get acquired. At that point, your title is what your new overlords will use to determine your role, salary, and even whether to lay you off.
I've seen that happen to an excellent domain expert at a company during radical downsizing. Though TBF, that round saw fat, muscle, sinew, and bone cut.
Been doing this professionally 15 years, and still am enamored with tech and programming. I actually avoided getting into the field because I was worried it would ruin my favorite hobby if I did it professionally (which is why I majored in Philosophy instead of CS in college)
I get sick and tired of all the rest of the bullshit, but never with tech and programming itself.
It happened to me too. In fact I'm in the process of leaving the field for something else altogether. I do tend to get weird looks and "whys" when I mention it, but its difficult for me to really explain in a concrete way, but I've just lost all excitement and motivation to do anything with programming (despite my mind still operating in very much a hacker mindset, where I see X and thing "I bet I could make X do Y)
That's the thing, I've been trying to do that for years now. I've got about a dozen cool ideas that bounce around in my head and a new one every few months or so. I can spend all my non-free time thinking about and designing them in my head, but when it comes time to actually write the code, I just kinda lose all motivation.
Just do it at work. All this side project stuff is ok but a lot more stress (I.e. deep thought killer) than just being a bad attitude employee and doing something awesome because you think it will be good. Don’t spend too long on it. If your learn something, you win. If it is useful to other people at your job, double win. The worst type of employee or a software project is the well-intentioned sincerely obedient one. That is how mega disasters happen in software. Despite sprint scheduling stuff, you can take a week and play with some new stuff. You will look bad in Standup for a while, but cost of victory is looking bad for a little in some bogus unimportant context. When you finish the new thing, write a story for it and then sell the hell out of it to the other people.
I don't know. Possibly it's simply because when you accept a career in the thing you're passionate about the thing you're passionate about becomes work.
Another thought that has occurred to me of late: when I started in this field it was "Computers" (capital "C") — a thing really by nerds, for nerds. Increasingly it's the web, mobile. Our "customers" are increasingly not us and so the decisions that would have come so readily to us on how to proceed, what features to implement are instead handed down to us from design, marketing....
Yeah, I don't think there's anything special about working in tech. I've seen the same exact dynamic happen in lots of other fields. People who love cooking and become professional chefs only to leave after a few years is extremely common, for instance.
So much so that I would have said it is pretty common advice that if you try to turn a hobby you love into a job, there's a good chance you'll end up losing your passion for it.
I still love programming and if I wasn't working I'd be doing it as a hobby. But its halfway satiated/suppressed by the sheer amount of it I have to do every week now.
There are quite a few topics in CS I like, from compiler construction to robotics. That was the "hacker tech" for me. For a long time, I managed to have work with an interesting angle, but slowly it got to the point where I'm solving a fucking npm caching problem that caused a junior headaches, moving a server with an EOL OS with minimal service interruption, looking for another 2FA mechanism, and getting older tools to play well with mobile. None of it is interesting, and it takes a lot of time.
Not that it used to be better: many of my fellow students ended up in business administration. Some might even be architecturing COBOL systems on an IBM mainframe.
The other day, I started playing this game called TIS-100. The game simulates something like assembly programming and I had so much fun with it. Then I realized it’s been nearly half a year that I’ve actually written proper code for something (rather than a GitHub workflow script or account provision mechanism for testing framework) and built something that I was actually proud of.
The love and passion are still there, but their buried under the needs of my current mediocre job. I need to find a position that will let be get back to the task of building things again, rather than just tweaking scripts and keeping the machinery humming.
I know this is a tangent to your main point, but in case you haven't already done so, check out some of the other Zachtronics games. SpaceChem is my favourite; it's not literally a programming game like TIS-100, but conceptually it pretty much is.
They also have another game (the name of which escapes me right now) that is sort of like a bigger version of TIS-100, where you have to write code for microprocessors. I didn't get into that one -- it was a bit less pure and straight to the point compared to TIS-100 or SpaceChem, and one of my favourite things about those games is their fundamental simplicity and transparency -- but I've heard it is good too.
Part of the problem is, to borrow an analogy, the frame has gotten really big and the space for the painting is smaller. We recently finished a two or four sprint to ... deploy yellow world. It has bitbucket pieces, Jenkins pieces, EKS terraform, et.c etc., we were all super happy that it worked, but it doesn’t do as much as you can do with twenty minutes in basic in a 1990 PC. And most of the people that wired all this stuff together can’t even write code to draw parabolas or calculate or whatever. It used to be I would develop for a few months then spend a week or two getting stuff in production, for new projects, or few days adding features/bug fixing form existing code, then get it shipped in a few days. There was thorough testing thru code all along, and evil network layers, and so on., and most of the head space was in the code. Now it seems like teams end up spending months trying to get a docker image with all their dependencies and yaml files and so on. And the code is just taking some SQL that ran in a database and running it on some new cloud platform that is still solving acid problems Oracle mastered twenty years ago. Half the code is just orchestration run this hello world Spark job that moves data from here to there. It is cobol level Scala.
Being the best coder doesn’t make customers want your product. So at a certain point, I got over coding. I am now more interested in business and product managements.
I think I’d feel that way to if I had stayed in web development (which I only did as a short stint many years ago by now), and I felt it happening already.
It just doesn’t have much to do with computers and technology in the specific ways that I got enamored with computers and technology. Playing with bare metal stuff at work does. Of course, for someone else it might be the opposite.
Perhaps because we don't feel productive anymore. 90% of the day is meetings, slack, and dealing with production issues because of the unnecessary complexity, then the last 5%-10% of your time is developing - usually involving getting JSON to and from a database.
I think it’s ok. That quote describes me too. There are lots of things to be interested in and excited by in life, computers are only a very very small thing. So don’t be saddened.
For me it’s almost like a graduation or transcending, getting so worked up about the details of computer shit just seems so silly nowadays. It’s actually quite dry and dull when you get down to it. There is a lot more to life.
Clojure goes against so many of lisp's timeless philosophies and principles that it can hardly be described as a lisp.
When someone says "lisp is the greatest programming language" it's these principles that they refer to, most of which Clojure discards so it can play nice with Java and promote very specialized ways of solving problems in order to best fit a particular niche.
The best way to discover the essence of lisp is to read SICP and learn Scheme.
I think there is Clojure and cloJure. The language is very different if you can mostly get by writing pure Clojure code, and another language altogether if you need to interop with Java constantly.
If you can get by mostly writing Clojure code (either by wrapping the Java libraries that you will use on helpers, or by using third-party libraries), it is a great language, even if in the end it is a very different from any other Lisp (but I'd argue that the changes are for the better, for example first instead of car, thread macros, protocols, immutable data structures). But yeah, for sure Clojure is much more optionated than any other Lisp.
Now, if you need to interop with Java code constantly, yeah, Clojure can be a pain. A good chunk of the code you will write goes to appease the alien structure that is the concept of Class on a FP language.
There it is again. Care to name any of those timeless philosophies without resorting to the minutiae of cons cells?
Clojure has very tangible and definite downsides and tradfeoffs (to name some: weaker REPL, though not as weak as some Schemes. JVM required. Heavy interop reliance), but it has served well as the flagship functional lisp.
This, and the current “sober” posts on r/ExperiencedDevs, makes me think of Herodotus describing the way the Persians made important decisions - once sober, once drunk, and if the drunk and sober decisions were the same they knew it was a good one.
This is right for the drunken dev thoughts, but not for the Herodotus example. "In vino veritas" - in wine there is truth - means that people expose their true thoughts when they're drunk rather than the filtered version they might present when sober, but the story of the Persians is more about the fact that there's value in considering both drunk and sober reactions, particularly when they tally.
Oh the Ballmer peak definitely exists for POCs, school work and side projects. A couple beers in and then you lose the fear of doing something stupid and start cranking out code.
Not sure about producfion code though, the values are different
Sort of a guilty secret but I used to save POC work for right after a company talk or party and a few beers. I could spew out a few hundred lines of code that was a bit messy but was got the job done. I’d go over it and clean it all up the next morning. Almost always an incredibly productive exercise for me but ymmv.
Alcohol really does not help me with code either (except maybe a relaxing beer), but Marijuhana works(occasionally). But you really, really need to do the sober clean up part. Otherwise it becomes a mess.
I cannot work while stoned - velocity drops to a crawl, and any complexity becomes overwhelming. And dealing with colleagues becomes much more difficult.
I can code with a few drinks in me; in fact the activity of coding seems to reduce the amount I drink (I'm a functioning alcoholic).
It's decades since I drank during working hours. In my early career in the City, it was the custom to drink at lunchtime. Those days are passed.
I think Tacitus had a similar anecdote about the Germans.
(Even without getting drunk, I've always found it useful to consider a hard decision once analytically and once intuitively, and if I don't agree with myself, think about it some more.)
>Don't meet your heroes. I paid 5k to take a course by one of my heroes. He's a brilliant man, but at the end of it I realized that he's making it up as he goes along like the rest of us.
I thought they were going to go the direction of "he's an asshole" and was ready to accept that, but this particular criticism is actually disturbing. People with strong visions can often appear to be "making it up as they go along," when really they are just subpar communicators.
Short story, I am helping my current company switch from a monolith to service-oriented architecture, and in the process have built a framework for spinning up new fully-deployable services from scratch that gets engineers 90% of the way there (minus the business logic). I have a strong vision for how it works and had a dozen-page RFC accepted by the engineering team for it. Yet there are engineers who think I am making it up as I go (I have been asked this indirectly), without any vision guiding the pieces into place. I have chalked up this feedback to me needing to improve my communication of the vision.
So the post's response of "I realized that he's making it up as he goes along like the rest of us" is disturbing because it makes me realize just how difficult communicating a vision is... if this hero that the poster paid $5k to go see can't even convince one of their fans, what chance do normal people like you and I have of convincing people that we're not making it up as we go?
>EDIT: I realize that I am posting under the assumption that the person's hero does in fact know what he's doing. If he truly is making it up as he goes, the above doesn't apply.
A common meme I've seen recently is "no one knows what they're doing".
I think people like to believe this because it helps them cope with impostor syndrome, or maybe they think it puts them on even ground with people who do in fact know what they're doing.
It's clearly not true in all circumstances. You can bet that an airline pilot has a very clear idea of what they are doing, and so will your dentist. Closer to home there are plenty of sub-fields in software where I'd be completely lost but when (say) we have to add a new endpoint to the webservice I work with, I absolutely don't have to make it up as I go along.
Your assessment of why people like to believe this seems spot on.
i grew up a long time before stack overflow. actually used man pages and read books. there is just _no way_ to program in Rust or Go without access to a search engine and the package libraries.
I've done various rust and clojure projects by downloading a lot of git repos ahead of time for reference while on a long-haul flight. This works pretty well, but you need to do a bit of research ahead of time on which libraries you might want access to. This is probably slower, as you have to read source code and think more about the type signatures (rather than looking at some misc example), but if you have 15 hours, what else are you going to do?
You can spin up godoc locally and access it locally fyi. Wont help pull in a new package. And you can always drill down into the stdlib implementation right from your editor if you have jump to declaration. I wrote a custom consensus protocol implementation in Go on a flight for work sans wifi.
"For some the productivity drops to zero without stack overflow."
And it is bad to be a newb? And even for experienced devs to go to stackoverflow regulary ... isn't it productive, to not always reinvent the wheel?
I can solve allmost everything on my own. But if I have a new problem, I assume someone else already had - I would be stupid, to figure it out on my own, when I could get a working solution in 5 min googling.
But I actually programm without internet connection most of the time, as I like being outside, away from noise (and wifi)
The issue does arise when you aren’t able to understand the problem space enough to realize that what you copied from stack overflow has a mistake or doesn’t fit the requirement you need (e.g. perhaps it doesn’t match your error handling architecture or so on).
That said, stack overflow can be a great source and I’ve written plenty of code with a comment pointing to a SO link to further explain a pattern or snippet for a future reader.
"The issue does arise when you aren’t able to understand the problem space enough to realize that what you copied from stack overflow has a mistake or doesn’t fit the requirement you need "
Yeah sure. A stupid programmer will remain a stupid programmer, even if he reaches a certain productivity by living off of stackoverflow ...
There is nothing wrong with copy pasting code from stack overflow.
I do see two kind of people doing that. One group learns from the code in order to become better, and can use it over and over to be more efficient. The other group doesn't care how it works and just wants to have a snippet that works.
The second group usually misses a curiosity, of which the effects show up in many more places than just copy pasting from stack overflow. They also tend to have a flatter learning curve. I don't want to generalize, but in this group you will encounter people who don't care about the difference between a list and a set, or think that code works when it compiles. In both cases the juniors know very little, but one grows and the other one doesn't (or less)
There is space for both in the world, but I prefer the first group in my team.
My model for people who "know what they're doing" is that they tend to have a well-organized hierarchy of rules. At the base are principles; at the top are opinions.
The foundation tends to be pretty simple, deeply held, and unchanging, while the higher levels are increasingly fluid and specialized. The higher you get on this stack, the more "making it up as you go along" it becomes, but every improvised part is perched on something more stable.
They key to "knowing what you're doing" is organizing this hierarchy well, having the right supports in place to successfully guide improvisation and course-correction while steadily fortifying the foundation.
I take this really just to mean "everyone has faults".
People often idealize heroes and think of them as beyond human. If you do that and met your hero then your illusion will often be shattered. But the problem is just that you were putting them on an unreasonable pedestal.
Of course some people are frauds and some people have no idea what they are doing but manage to make people think they do. But I didn't read this as being one of those situations. Just someone they saw as beyond human being only human.
I like the phrase “kill your heroes”. Not literally, of course. But in your mind. They are just flawed people like everyone else that happen to have been mythologized. Learning more about your heroes often leads to disappointment.
I've recently found a podcast called "your favorite band sucks" that's along these lines. They have real criticisms of popular bands, but it's also a bit tounge-in-cheek. It's a nice contrast to the typical worship of rock bands. I think it's healthy to be able to enjoy something, or be inspired by someone, without buying into the mythology.
What is wrong with making it up as you go? I mean everything I've ever built I had a notion of what I was doing but most of the real work was in the details. Anyone could say I was making it up as I go. I'd be like yeah, if I knew completely how to do it, I'd already be finished it.
Then there's the times where you think you know exactly what you're doing and after going down a road you realize it's the wrong way. Failing to learn and see the signs and make the embarrassing declaration that you got lost and need to turn around is never good. But some people just keep driving. It's hard though when there's a big line of cars behind you that think you actually know where you are headed.
Nothing wrong with making it up as you go, and I didn't mean to sound like I was knocking it, if I did. Sometimes everyone fumbles around trying to find solutions that work...it's a totally valid way to approach some problems.
Sometimes it's a hybrid of knowing what you are doing but not knowing the implementation specifics. You know you need to connect high-level pieces A, B, and C with specific constraints, but it won't be until you get into the low-level implementation that you'll know if it is indeed possible. I think that's an example of both having a vision and also improvising as you go.
I am concerned about how to effectively communicate visions to people, because it gets everyone rowing in the same direction. If nobody thinks that you have a vision, when you do, there is no reason they should choose your direction vs just do their own thing.
Ok this is helpful. If people are doing their own thing and not following the established, agreed on (or even dictated) way or vision, then you need to figure out why if you are the lead.
Maybe it is communication related. Does everyone know that this is the way they should do something? But they still don't? Have you created docs and edicts around these areas? Have you been assertive in code reviews? Have you been proactive and requested design sessions before a lot of work was done?
Has a decision been formally communicated? I see this step not happening enough, people are hesitant to be authoritative after a discussion on architectural concerns. If you are the lead, that needs to happen.
Most of the time it's simply a case of them not knowing how to do it. People are afraid to show their lack of skill and knowledge and ask for help. They get deadline pressure and deliver their default way.
Have you provided a feature or cut through the system that shows this vision for people to follow? Maybe example code, resources on the web that go very deep into the ideas and tactics? Have you paired with them to help them get started or get over obstacles. Perhaps pair your most senior person with juniors for a while to get them on the same page and capable with this vision.
Using a phrase like "fumbles around" still sounds like you're placing it on a lower rung, whereas I would say that basically everything I've ever done has been an iterative, collaborative process, including in situations where I'm highly confident of both the problem domain and technology choices. There are always going to be new discoveries made during implementation, and you can't have a written-in-stone design doc that prevents anyone on the team suggesting a refinement.
For myself as an opinionated person in a devops role, the vision that I try to communicate to my colleagues is mostly broad principles like configuration as code, helping people help themselves, consolidation of systems, and then some more pointed specifics like don't touch prod, don't make changes without a consensus, start by understanding why it's the way it is before changing it, etc.
>I am concerned about how to effectively communicate visions to people, because it gets everyone rowing in the same direction. If nobody thinks that you have a vision, when you do, there is no reason they should choose your direction vs just do their own thing.
I used to have visions. Now I have collaborative design discussions driven by some starting designs. I found that if people don't contribute to the overall design then they have little impetus to actually understand it. This tends to lead to a better design and a more engaged team so a win on all counts.
Nothing if you're good at it. But if you're hoping to learn something from someone, it is pretty disappointing. How to make it up as you go along is far less teachable.
The criticism may depend on different values of "making it up as you go along", i.e., it may not mean so much "just wing it in ignorance" vs something like "even if you have many answers you don't yet have all of them, and new answers generate new questions exponentially...". So, perhaps less "everyone's ignorant" vs "we're all living in a land of many unknowns". But, yeah, he did find it disillusioning, and maybe is over-generalizing from a one-off experience (in contrast, I've done similar and was nothing but impressed, finding it is extremely valuable to learn from the best in a field).
How do you distinguish between what you do and "making it up as you go along"?
> built a framework for spinning up new fully-deployable services from scratch that gets engineers 90% of the way there (minus the business logic)
I'm guessing that this was based on first-hand experience building such services and witnessing engineers struggle getting new services up. And not so much that you've had specific training or past experience in developing bootstrapping frameworks. This would be my definition of making it up as you go and is great way to do it. Another way is learning how to make bootstrapping frameworks and applying it wherever you can which doesn't go as well.
Related thing I'd add: be very careful about taking a dream job; I've seen this happen a few times--it's likely to disappoint. Also dating a minor celebrity crush.
I "know" guy who's conference speaker, so he knows other conference speakers, drinks vodka with them and so on.
He says there's significant amount of bullshit aka things that work nice on slides, things that only work cool in theory, but in practice they arent as great
Building a new framework should be way at the bottom of your list of things to consider. If you do, please make it a blackbox.
It's tiring how many details one often needs to get into before being able to do something they could have summarized in a sentence the whole time. But this is a general issue!
In your particular instance, I would have collaborated with a single team to work on converting a single service over to the new framework. Once some success was made, it would be much easier to make traction with other projects and teams. Also, a vision or a plan doesn't mean you're not winging things as you go.
IME most people will generally appear to be making things up as they go – even if they have significant relevant experience. Every situation is unique, and experience tends to look more like having a list of techniques with varying degrees of expertise, rather than having a playbook for every situation. You have to look for the expertise rather than raw confidence.
In sports terms it would be something like a baseball pitcher being able to throw a great curveball, a great fastball, and an all right slider, and knowing roughly what situations to use them in. There will still be a high degree of randomness and mistakes will be made.
Agreed. What experience and talent gives you are instincts that improve the chances of whatever it is "you're making up as you go" working well.
I would much rather work with people who have a good track record of making it up as they go as opposed to people coming in with a fixed idea of how something should happen and are more likely to misapply whatever lessons led to those views (probably someone elses anyway).
> If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.
Yes, something is wrong. But it could be many things. Here is how you can find out:
1. Is the thing that's broken a bug in your code? Then it's your fault, so fix it. This means you need better testing too, and maybe a redesign to resist failures. Try to get alerts at 9am in dev so that they don't come in at 2am from production.
2. Is the thing that's broken a server thing that Ops is supposed to deal with? Probably you should quit. You can also work with Ops to redesign the server stuff to be something less prone to failure. Often Ops can't do this themselves because they don't know enough about how your apps work. Go talk to them, help them out. Or quit.
3. Is the thing that's broken a false alarm, or not important? Quit. Or work with Ops to create better alarms and tests. Ops doesn't know your app, so you need to help them craft the SLIs and SLOs.
4. Did Ops create all these alerts themselves without your involvement? Quit. Or take ownership of the tests and alerts for your apps.
5. Is it a huge slog to try to figure out how the alerting works, to work with Ops to make changes, to add tests, or to figure out what's broken or not and troubleshoot it? Definitely quit.
> If I'm awaken at 2am from being on-call for more than once per quarter, then something is seriously wrong and I will either fix it or quit.
Sometimes fixing the problem will require special access to Production which you don't have, or even a specific role with that extra bit of initiative.
If you're frequently being paged for stuff you literally can't fix, then the process/monitoring/alerting has broken down somewhere and needs to be fixed. If it can't/won't be fixed, then the company needs to hire ops people whose specific job is to react to and triage system failures -- devs should not be treated as escalation machines. If the process can't be fixed and the company won't hire people to handle the process, then you quit.
Very true. I do ops, I'm on call. Calling a developer at 3.00AM is not something I do lightly, it would have to be insanely critical.
Operation, and on-call staff fixes broken systems just enough, that they will work until 8:00AM when the developer is back at work.
Just this week I talked to a developer, and he asked if I could switch the phone numbers, so issues would get routed to him first. My question: Why? You can't really do much without me being awake as well, so maybe I get the first call, and I call you... IF I need to?
This is true unless you own a meaningful portion of the company (>1%). To dump your entire investment because of extra hours is not a way to get that asymptotic upside.
Maybe... none of this applies to people who own meaningful portions of the companies they work for.
> Good people write shitty code. Smart people write shitty code. Good coders and good engineers write shitty code. Don't let code quality be a dependent variable on your self worth.
That's like saying that eminent book authors write shitty books. Sounds like an excuse.
> I've become what I've always hated: someone who works in tech in a career but avoid tech in real life. Maybe that comes with being old.
It's all about finding the right project. REST + CRUD shit gets exhausting after 5 years. There's an entire world of excitement outside of REST + CRUD.
>I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so little.
Full stack compresses two jobs into one. It's purely for cost-savings. They're paid so little because companies revert to "well, you can still only do 8 hours, so you do half as much of each", but really that's just them trying to weasel out of paying for knowledge. They also blur the lines by putting full stack along-side other devs, even though the other devs may not have invested the same time to gain as much knowledge as full stack.
When you take a full stack job, you undervalue your knowledge (and the time invested) and are selling it for roughly half of what it's worth.
I would do "full-stack" over a decade ago, when there was less of the notion of "front-end engineer" (which still sound a bit ridiculous to me) - the front-end was mostly HTML and CSS. It was a good experience, to go from requirements gathering to the database schema and back to presentation - it helped me see the whole picture.
There's also an issue with how many full stack web developers who are actually capable of doing all the things he lists.
My experience is that at some scale it works out okay, but beyond a certain point it just falls flat for most. We deal with insanely talented developers, who will trash a database, because it don't understand how it works. Talented JavaScript developers, who don't really understand how HTTP works... or load balancers, or caching... or webservers. Sometimes you get these fantastic software machines as deliverables, complex, you can't monitor them, or configure much, and the it just implements a basic feature of HA-Proxy or Apache, but badly.
My point is that they should be paid poorly, because they fail to be excellent at every part of their job, but rather than: Yes, this should in most cases not even be a job title. If you find someone who can do all of this well, you almost can't overpay, but are you really sure that you want to tie everything up on one person anyway?
I've been a "full-stack" developer at large tech companies, and my experience is there at least it means "frontend developer who can put together a basic API server". My fellow full-stack developers and I would spend most of our time building out frontends, which was generally regarded by others as challenging and specialized work, and maybe 20% of the time adding API endpoints to fetch or update some data, which was considered straightforward.[0]
Not having to wait for some other engineer to make the backends made us a lot more efficient. It definitely was rewarding to be able to complete products end-to-end.
Hiring standards and pay were the same as for any engineer, at least in FAANG.
[0] Yeah, occasionally we had to optimize some SQL queries or whatever but we're competent engineers, we can figure it out even if it's not what we do every day.
> my experience [full-stack] means "frontend developer who can put together a basic API server"
This is 100% accurate in my experience too, and it's also true in the other way around: "full-stack" means backend developer who can put a basic SPA using React/Vue.
From the frontend perspective: they call themselves full-stacks for knowing how to spin up a NodeJS HTTP Server powered by Express with MongoDB inserting JSON in the database. But they are missing:
- AWS/cloud computing: not necessarily creating the infrastructure (although that's a must on more senior levels), but how to orchestrate the different components together.
- databases: why SQL/NoSQL, beyond basic SELECTs, knowing how to properly add indexes, debug why queries are slow, modeling, understanding locks implications and transaction levels, and so on.
- tooling: how to set up a bundler, linter and formatter, testing, CI/CD. This overlaps a bit with the responsibilities of the DevOps engineer, but a full-stack should know at least on intermediate level all of those things. I can't say how many times I've seen "senior full-stacks" that had no clue about how webpack worked at all.
From the backend perspective: they call themselves full-stacks for knowing how to spin up a React/Vue app that does basic CRUD operations using forms, powered by a UI framework like Material UI. But they are missing:
- CSS: most will find CSS hard/annoying and won't bother understanding at all how it works even on a fundamental level, will defer to hacks most of the time to make things work, especially when it comes to adjusting for edge cases like responsive design or cross-browser support.
- the DOM: normally they don't understand it at all, or to a very limited extent.
- Web vitals: how to measure and makes things faster and performant—not really including here overly optimized, but just making sure your app is 60fps or close to that most of the time. Usually when things get slow either on the network side or in the app itself, those engineers will blame is the framework/library, not their misusage of it.
--
Those lists are definitely non-exhaustive, as I didn't even mention more advanced stuff like protocols (how HTTP works? most can't answer), caching, etc etc, but you can get the point I'm trying to make:
The problem with the term full-stack is that only very few engineers really are sufficiently great on both sides of the stack and could say that they mastered both, simply because there's just too much to learn! Frontend has become so much more complex with SPAs compared when it was about rendering static HTML with some CSS and basic behavior with jQuery. Same for backend with the advent of cloud computing and several types of databases.
I've been coding professionally for a decade and I've met only a single engineer that I'd consider him full-stack (he checked all those boxes I mentioned and more). I think I would also include myself, because I spent 50% of my career spent as a front-end engineer, became senior, then I transitioned to back-end engineering because it pays the same or more and it's less stressful (for most of the regular companies that most of us work at). My current title is "principal full stack engineer", but in practice I only do backend/devops, I don't actively code front-end but I keep up with the industry by following the new trends and testing things here and there in personal projects.
Ultimately, I believe for being a full-stack engineer you have to be first a front-end (or back-end engineer) then learn the other, what we have today is most people doing the same from the very beginning of their careers and they either go deep on a single one or in none of them.
Full stack is not really a skill level qualifier - that's what junior, senior, principal, staff, etc. are for. It means you work in different areas and can't say "oh I don't do that work here" when someone gives you work in those areas. People call themselves front or back end engineers long before they've mastered it, and you don't have to wait for full stack either.
The front or backend bias you and your parent's comment talk about are team specific things so you don't give a hard front-end task to someone who is biased towards the backend. That still means they can take the less difficult tickets.
You can replace full stack for your example with "extremely good/talented/gifted engineer" and I'm almost sure it has nothing to do with the full stack label because it's the only example in a decade you've found.
But also the jobs that they get feed back into what they call themselves. So even if that's your example, it isn't how the business defines it, which IMO is ultimately why it's just a cost savings label to get people to work harder for similar amounts of pay as front or backend people.
Full-stack developer knows some frontend, some backend, some sql. They are paid good money because they are convenient, not for their knowledge. A dev who does only one thing knows way more about it that a team of full-stack devs.
Full-stack devs earn a lot and will probably earn only more in the future.
This is mostly a result of tech advancements like cloud infrastructure, tools etc that takes all the hardest things from you - like managing a DB, implementing security, managing infrastructure, deployments etc.
You don't need deep experts because of it, generalists are perfect for quickly shipping new features.
> Tech stack matters. OK I just said tech stack doesn't matter, but hear me out. If you hear Python dev vs C++ dev, you think very different things, right? That's because certain tools are really good at certain jobs. If you're not sure what you want to do, just do Java. It's a shitty programming language that's good at almost everything.
It has one of the more confusing interfaces I've seen, and operator overloading just makes it worse. Numpy, on the other hand, is fairly straightforward and intuitive (and to be fair, a much simpler tool).
They basically created a DSL within Python. It's a total nightmare unless you're someone who uses it in notebooks every day (and it's impossible to typecheck)
Ive never had a good experience with whiteboard paint. The walls are not smooth so you always leave some residue when removing the ink. Over time it becomes pretty noticeable unless you spend a significant amount of elbow grease cleaning it.
I think HN is big enough that you're not going to beat the averages with advice from the comments here. They're filled with the kinds of opinions that are more popular on big company teams than good startup teams.
> The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.)
Highly recommend a journalism class at local community college.
I studied journalism at college as part of a more general media studies course.
It does help but I am not sure I would describe _my_ education as a panacea.
The main reason it was good was because it helps frame how you think of writing,
The most important things go first. Statement of fact, then you go into what the implications are, then you start introducing less and less relevant elements.
when you’re writing you keep the 5 “W’s” in mind, make sure you answer them. (Who what where when why), for instructive documentation you add: How.
Obviously an education bakes this into you in a better way than I can convey here.
What I learned is probably only decent for writing overviews.
Personally I find structure to be the biggest bottleneck/difficulty when making documentation.
What do others normally struggle with that don’t have this education?
Or just learn how to take notes. Notes should be made with the intent that someone new could understand what's going on. With that approach, if you can't make good notes, you're thinking too much about what you know and less about what others don't.
Yeah. I'm nominally a full-stack developer, but I know fuck-all about React; I can maintain an existing project, but it would take me a significant amount of effort and googling to kickstart one from scratch, and diagnosing and debugging issues and writing effective tests is always a struggle.
YUP. They're "two jobs", but I've yet to work with a full stack developer who is master of either. Most commonly they're great at front end, and have a very superficial understanding of how to do anything on the backend, and even then the backend basically has to be node.js for them to contribute. No way am I getting them to change the database schema or build a new service.
509 comments
[ 3.1 ms ] story [ 367 ms ] threadso either i’m doing OK, or we’re both fucked…
I agree but think it is more than just _documentation_: effectively communicating ideas through text was one of the most underrated skills in software engineering. I say "was" as I think there is much more focus on it now with remote work and video call fatigue becoming the norm for many.
It works very well, and doesn't really add any overhead to my work.
I write about how I do documentation here: https://littlegreenviper.com/miscellany/leaving-a-legacy/
It's a long read, because it's a big topic.
Depending on the project, various other documents may be required, e.g. installation guide, user guide, operations manual, architecture diagrams, networking diagrams, module/component diagrams, information flow diagrams, high-level design, low-level design, docs at various "views" (such as "business view", "information view", "technology view"), design decision tracker, ontology...
I'm actually in the middle of using Postman to generate a more "modern" inline docset for a new engineer that is coming into a project that uses that server.
But I also like to keep docs to a bare minimum, as they become what I term "concrete galoshes": https://littlegreenviper.com/miscellany/concrete-galoshes/
We need to be very careful, as the docs can prevent agility, in a big way.
I find that if I can keep the docs pinned to the code, itself, as much as possible, it helps to keep some flexibility.
Totally agree about not having too much documentation - sometimes outdated documentations is worse than no documentation at all.
learning-oriented tutorials
goal-oriented how-to guides
understanding-oriented explanations or discussions
information-oriented reference material
https://www.writethedocs.org/videos/eu/2017/the-four-kinds-o...
Two important lessons I learned:
1. Formatting and direct communication is very useful. It can make the difference between someone stopping and noticing critical information, or skipping it because they're lazy readers.
2. You probably don't know the correct way to convey information, and the audience probably doesn't know how to tell you how to convey it either. You need to listen for when the docs fail: when somebody says they read the docs but still don't know something or don't do something right. That means your doc has a "bug" in how it gets through to the reader. Experiment, change things around, add/remove information, etc until the bug is gone.
And it turns out those kinds of docs are pretty useful to my colleagues in piecing it together also.
* Rust Library Documentation: Most libraries have complete and up-to-date reference documentation, but are lacking even basic introductions (tutorials/guides) on how to use the library. This is totally just my personal experience so maybe I've been looking at the wrong crates, but with most of the crates I spend several minutes looking trough all the modules in order to find that all the juicy functions are hidden in the Connection struct, or something similar.
* Linux Kernel Documentation: The Linux kernel has excellent in-depth explanations on several high-level concepts, but on the other hand a little more systematic reference documentation on the supporting library code would help a lot.
* While I can't think of a good example right now, a lot of projects have a few basic getting-started tutorials but don't explain advanced concepts or high-level design at all, leaving you to wade through the sources yourself in order to understand how to actually use them.
And management is usually/always ok with this short-term optimization.
Trying to write ops documentation on an unfinished project can be this way.
Code says what is done. Docs says why
Like dude, tell us why we should read the code in the first place.
People managing work, from what I've seen, still prefer to babble over their scribbled 5 basic points than taking the time to do their job and create relevant textual information. Then you listen, you take notes, and then you go and produce whatever documentation of the objective is required to at least understand if it's going to work. Of course you still will have gaps in your understanding, so then more calls, and repeat. In the end, unnecessary/missing features, a whole bunch of time wasted in crap, deadlines missed, burnt time, all of which could have been avoided if someone just had taken the time to do their supposed job - this is not to say it wouldn't have to be discussed, or that there's no need for back and forth and calls, etc, it's just instead of starting halfway you start from -50% or something.
Even in outsourcing platforms there's been a shift contrary to that. At least two years ago and before that, video calls or calls weren't really usual unless you were in some months long collaboration - now even there everyone expects video calls on the interview... It doesn't matter if it's a $100 one time job or whatever.
That said, I find high-level documentation for larger systems to be very valuable. I also find Python's docs to be lacking compared to Java's; I'm often left wondering about the definition of what type is returned, exactly what parameters should be, and which exceptions are raised. Java's docs are very explicit about all these things.
I'm a pretty firm believer that documentation has to live next to the code. Otherwise it's nearly guaranteed to be out of date and/or incomplete
Thoroughly commented code tends to end up a couple changes out of date. A separate file in the same directory ends up a couple major refactors out of date. A separate file in a separate system ends up a couple company-wide reorgs out of date.
Absolutely. So many hour long meetings could be shortened by better communication skills (just more targeted), or even a small email chain.
Communicating in short form confidently is a skill. Many people, including myself (something I've been working on) struggle with saying something that was a complete idea in a meeting and not stopping because they feel like they need to say more. Short and sweet is the way to go pretty much whenever you can, for technical work that is.
I find 'small email chains' don't help at all. Too many people just don't read past the first sentence or paragraph. And email is slow.
I usually 'escalate' quickly. Support didn't understand a ticket comment I made on how this isn't a bug or why there really is a workaround for it?
I send them an IM trying to coax it out of them/get them to understand for a few minutes. Doesn't work? Quick call and do screen sharing. Problem usually solved after a few minutes. Problem is they might stay longer than that took just to 'catch up' ;)
This is really not that different from when we were all at the office just that the last part would be walking over to their office and looking at the computer together. In some situations that makes it even easier nowadays because I don't need to take an elevator down 20 stories and back up again after.
Having asynchronous means of communication is great. But as soon as the back and forth is more than maybe twice on each side, there's probably a miscommunication happening somehow that will be much easier to get solved with a really short feedback loop. Some people you have to call right away coz they just type soooooo slowly ;)
So I argue that the issue is writing skills, of which technical documentation is a subset speciality of writing skills. I will add, similar to math problems or programming, writing wants you to do it over and over so it can get better.
Agreed, wholeheartedly. Will hitchhike on your comment to recommend two things: Brett Victor's pdf stash [1] and, specifically, the Walter Ong essay "The Writer's Audience is Always a Fiction"[2].
Long story short, we form our audiences by subjecting them to our writing. In writing software documentation, we are implicitly informing the next generation's thought by the simple power dynamic that underlies all technical documentation: "you must understand this in order to do your job properly".
It is no wonder that "form", "inform", and "information" are such closely related words.
We dictate the level of rigor and intelligibility we expect out of our technical documentation, when we write technical documents. It almost sounds like a tautology when put this way, but "bad docs" are exclusively the result of a professional culture that puts up with the existence of bad docs. I've been there; too tired and overworked to care about writing something properly, or wanting to avoid writing a doc enough that I setup some autodoc thing and called it a day. We literally don't get paid for writing documentation.
But good documentation is what made us into good developers (if we are good developers). We should get paid for doing that...
[1] http://worrydream.com/refs/
[2] http://worrydream.com/refs/Ong%20-%20The%20Writer's%20Audien...
And communicating gets even more important the higher up you move in your seniority.
Example 1 - too much details. Morning stand up. Manager: what's the status of that new feature. Senior Engineer: well I tried to call that service but it was timing out so I spoke to Bob and he said to check with DBA on why that stored procedure but it's so slow and turns out index is missing so we tried to add it but mysql and varchar something fckn something...
Dude couldn't you just tell it's delayed due to DB and then expand if needed.
Example 2 - insufficient details I return from the meeting and discover avalanche of emails, chat messages and urgent meeting invite, all with same topic - "Blah service fails, we are blocked" but no details apart from that. On the call I get description of the problem - blah service fails and how everyone is blocked and how infinitely critical it is and what ETA for resolution would be. What endpoint? How does it fail - timeout, connection aborted, 503 response, 200 response but with error message?
Having links to actual code, like GoDocs have it, is something I appreciate too.
Amen! Not just junior engineers. PMs, analysts, testers. We all have a lot to learn from the rest of the team!
This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.
codex bonus a discipulo prendatur
codex magnus a novo prendatur
codex optimus nullus est
Part of the problem is I couldn't find any good word for "code". "Codex" sounds cool but may not be the best fit here.
EDIT: Forgot a word. Also, I think "prendere" is better for "understood" here than "scire", which is more like "to know".
EDIT2: My friend suggested using the subjunctive for "comprehend" so that it's "may be comprehended" instead of "is comprehended". Also I got the tense wrong initially and I think that's fixed now.
EDIT3: "Ablative agents" are a thing. This is a rough language. Thanks, James.
EDIT4: prendar -> prendatur; aka "oops, should have used third person"
Very frustrating.
In fact, I think a third-party auditor would be a valuable service for dev teams to utilize at least once a year. Totally neutral party that can come in and say ‘We’re pretty sure the codebase is too complex and we noticed the commits came from so and so’. The business value here is you can root-cause velocity issues that can come from decent people who need to be reigned in (not necessarily fired).
I’m literally prepared to pay to have these people objectively assessed.
One challenging bit about this service would definitely be quantifying improvements. Since the problem is somewhat hidden by nature, you would almost need testimonials from other engineers on the team.
If a team was tasked to make a simple landing page for example, and it was oddly hard or time consuming for an average team member, it would be good to dig into why. If the answer is ‘you should see the boilerplate involved, or the deploy process ...’, then you can make a neutral analysis as to the cause.
This sounds like it'd reduce psychological safety on the team, to have someone without the project context come in and criticize your engineers. The morale decline of such a choice could outweigh the benefits.
It’s a tough one, so I don’t even know where to begin other than an independent arbiter. Anyhow, I agree with you that it is a delicate matter from an emotional perspective (even though the underlying can be a reasonably objective matter).
someone then removed all of my logging because it was ugly.
and then had to put it all back in when another bug was coming from the same terse beautiful code.
1. good logging is the most important part of the app. whatever the app is meant to do is secondary. the app should be a logging app first, and then a backend service to sell widgets second.
2. assume performance requirements for request latency and transactions per second will be at least 3x whatever the product owner tells you at the start of the project and plan accordingly. never trust any suggestion that you can 'ignore performance for now'.
3. the UI may be more important than logging
I think it happens because most measures of code quality are quite fuzzy, but brevity (which is valuable, other things being equal) is relatively objective. "Have I made the code shorter?" is a much easier question to answer than "Have I made the code easier to understand, modify and maintain?"
This is something that comes with experience though, and I think a lot of people don't truly grok this until they are trying to maintain their own terse/clever code written months/years earlier. Nothing is quite as humbling as doing `git blame` on some crappy code only to see your own name there.
"A picture is worth a thousand words.."
I noticed that they put a lot of their self-worth in the sophistication of their code, so it's difficult to criticise without making them feel bad. You need alternative methods of getting them to "see the light" and write code that's more understandable and maintainable by others.
Also on PRs try to point to their own work as sample of how to do things better. This doesn't hurt the ego much, because the role model is themselves.
Also, I feel like most of the time this is an impostor-syndrome/perfectionism issue that also happens with other workers too, so HR can give tips on how to deal with those issues in a more sensible way and tell you what you can or can't say.
I've noticed this too. One thing I've had mild success with is the concept that a particular programming document (especially in functional programming) is really a series of mini-documents. Each mini-document has function-level comments, a signature, body, and returns that tell part of the story of what that function does. The minute that the collective of those fail me and I find myself reverse engineering code, then we have failed the team and cost the company money.
Some complicated things must be done, especially at the size and scale of our products, but complex things are painted with a fine veneer of interfaces and documentation.
I think another exercise that can help is putting junior engineers front and center to architecture. Whether it's exposing them to review, the review process of a Senior engineers design, or putting them front and center to design implications. I've seen having to figure out the difference between a controller and a service cause some really positive abstract thinking that puts people on the order of thinking for the group rather than their own merits.
I think this is more prevalent for some languages/stacks than others, too; there's definitely a cultural aspect fostered the language owners or whoever the leaders are.
If these systems are not in place, and a senior developer can get away with writing overly complex code, then that is the fault of management, not the developer.
Don't apply corporate best practice designed to withstand turnover to personal programming - you're leaving abstraction and efficiency on the table.
The better code for your own projects is almost definitely inscrutable to a newcomer a lot of the time. It's okay for there to be prerequisites to understanding.
Sometimes the simplest solution also requires learning and building upon other concepts. Or sometimes, a simple interface is written around a complicated core.
For example: The OP's quote is used time and time again to argue against FP concepts in industry - a newcomer doesn't know the first principles, so by the OP's folksy razor[1], that code isn't as good as less abstract code that doesn't require learning a new concept or two once and for all.
[1] Folksy razors are the essence of every principle-ish-level engineer's methodology I've run into. Corporations value the ability to remove all human agency & decision-making from software development where possible.
Corporations value the ability to continue as an operating entity and make changes to the code after the proponent of Kleisli arrows and lenses has departed for greener pastures.
That said, it's hard not to play the game and buy in. I just write my vanilla Java, say right-sounding things in meetings, and somehow get Paid despite barely doing a thing.
Corporate software development is a great career tbh - instead of paying me to use Kleisli arrows for the company's gain, the company effectively pays me to use Kleisli arrows on my own IP lmao. Gotta love all that frothy waste that's produced by Worse is Better. Waste that the average dev can now reap thanks to the boom in remote work!
e.g. I'll understand my monad transformers in a year, but a new hire with no Haskell experience will not.
A first-year student is unlikely to understand C++ template metaprogramming, or just about any Haskell code, but that's not to say they should always be avoided in production code.
> The best code is no code at all
This can be interpreted as advice to avoid the 'inner-platform effect' anti-pattern. Good advice, but personally I'd rather express it in terms of the inner-platform effect.
[0]: http://antirez.com/news/124
Agreed. Comments have their place, and some code is unavoidably involved, just by the nature of unavoidable complexity. The solution isn't always to write simple code. If it were, we wouldn't bother studying clever and efficient algorithms.
Also, it's important to ensure comments are updated when code is changed. I don't know who originally said it: Stale and inaccurate comments are no longer comments, they're lies.
That blog post looks worth reading properly, I admit so far I've only skimmed it.
They're just the people to read a book on the topic and try to use it everywhere...
Usually they end up thinking they can do a better job, decide to rewrite the thing from scratch, and take 10x longer to rewrite it than they thought it would take. And accomplish nothing in the end, because the thing they rewrote worked in the first place.
So I would say great code is code that:
1. Does its job well (robustly, performantly, etc. in whatever proportion is applicable)
2. Is maintainable by engineers with reasonable expertise in the tooling
in that order. If you can manage all that and make it accessible to your junior devs, that will of course make your code greater. But don't lose sight of what your customers care about. Your business isn't there to make you feel good about maintaining code, it's to provide customers with value.
How many entry level engineers come onto a project per year? 5? Is onboarding them onto the project is a deliberate and streamlined way such an undue burden that you must change your programming style to avoid it?
Then you'd be out of business.
Most likely the code I write has a bug in it. Or, at the time of writing, the customer requirement is fuzzy. Or, I have a limited grasp of the problem domain. Even if it is not any of the above, most likely there will be a change in a business requirement that impacts the code.
So whenever possible, I opt to write code that is either stupidly obvious, trivially testable, or easily replaceable.
What is better (A) a compiled bug free binary, or (B) well written source code that has a few bugs?
If you want to keep developing the software, the answer will always be (B).
There are code bases at my current employer that are entirely "ok" and still being worked on from before I was able to spell my name. Projects that have had continued development for >20 years by armies of engineers and the code is still readable and simple to understand.
In my experience, the easiest to maintain code is very often the most efficient and robust as well, because people haven't felt the need to hack around it at every corner.
Easy to understand code can be more quickly patched and repaired by anyone on the team. If you don't need to call in the senior who built it two years ago to repair it, and you can have someone do it right away, it is better for the customer.
That performant code that you wrote maybe at the expense of readability? It could very well become bad code when you leave the company and it falls to a junior engineer to modify it to fit some changing business requirement. Or, there’s a bug in the code and the amount of time it takes to fix it is a direct function of how quickly and completely that junior engineer can understand the code.
For me, the hard part is knowing when and how to make that trade off. I’ve definitely erred on both sides often enough.
1) Readable Interfaces usable by juniors when parts of the code will be used by lots of devs and will almost certainly change
2) Higher complexity behind the interface for parts of the code that change less often and require more skilled engineers
I am not saying the code cannot be made better or more clear. But, it also depends on who you are writing to. Somebody who is not familiar with certain style of programming cannot easily read the code of certain level of complexity.
When I was hacking away my first big program, I could not write functions. Or find reading functions easy. The whole thing was a big wall of glorified assembly sewn together by labels. I am not sure why I was like that then, but I found concepts 'functions' and recursion or any other conceptual stuff really hard. My code was, in its own twisted way, 'most simple' and utterly unreadable.
I find the same sort of difficulties while reading some FP snippets. I confess it was a very short affair, but I had some difficulty reading it and even when I understood, I could not just write or think code in the same style.
There are ways to make your code better, your intentions clear but 'can be understood by a first year CS freshman' is bit abstract criterion.
It is kind of like, vocabulary and prose. You can make your prose clear. But, people have to work on the vocabulary on their own.
> The best code is no code at all.
This is completely agreeable.
Edit : Changed some poor word choices. Added an analogy.
I real life working on a team with ever changing code, that is the barest rank minimum.
As a young programmer, I thought I was a master when I got the code to work. Now I know that is just the start. Making it readable and changeable is where real mastery lies.
This is very hard to convey to young fools as I used to be.
It works. I look at their code and think "that's neat", but you added 0 functionality while making it hard for the lowest half of the engineers to work with. You could have accomplished the same thing with hard-reference to a class.
AMEN to this. I've been in the industry for 20+ years and at this point I know so many different frameworks (front-end and back-end), databases (SQL and NoSQL), networking protocols, browser differences, ORMs, it goes on and on.
I'm paid what I barely consider adequate.
A lot of us have jobs because companies need to fulfill the image. It’s half the reason why so many people are allowed to do full-stack when in reality they would have no business dealing with those parts of the stack in a real operation.
So no, you don’t actually deserve more money because you are working on more things in an inconsequential space (e.g What the entire Peloton engineering team does is probably bullshit. You need maybe a few devs).
There are certainly better examples than Peloton, but that’s what came to mind (a home gym tech (lol) company). Can’t wait until Bowflex starts hiring out web developers.
Now I'm doing the same thing with another company with the web, expect I'm handling everything as a sole-engineer, full stack.
Here I'm dealing with creating an Angular application to replace an aging ASP.Net MVC app, having to rewrite hundreds of SOAP services into a proper REST architecture, and dealing with an Oracle database who's schema we need to keep in place. With a C# .Net Core back-end.
This company needs me, badly, but I doubt this is going to be come a cash cow either (no equity, just a paycheck, and their budget is tight).
Just doing my job as usual.
I'm doing all of this extra work because I think the best way to create value for a company is to make it easy for other/new developers to jump in to the project and contribute something of value quickly. My refactoring would have failed completely if other Dev's are not able to contribute the new code
The problem is they literally can't afford it. They looked at "near shoring" companies but they were too expensive. They said we got a quote for developers from another country who will do this work for $20/hour.
I explained that this has the potential of ruining a green-field project that absolutely needs to be architected and coded properly from the ground-up.
If we go that route the best I can do is enforce code standards and handle every pull-request.
Enforcing code standards and reviewing pull requests is a suitable role for a senior engineer. Not all things need to be architected, there's ton of glue stuff and features that can be developed by juniors provided the code around them is laid out nicely. Focus on the bigger picture, if u implement every little detail, then it starts to feel like everything is so important that it can only be done by you. That's a trap.
Then just assume the front-end will consume it and output a little, inconsequential DOM element here or there.
Uhm, sweety, just no.
I can develop a nice relational database design, write the SQL stored procedures to manipulate it, write a backend API and write the front end SPA for it. I don't think I'm an expert in any of those things though, and if I am then it's more focused on the backend API stuff.
Like, I understand CSS better than most people, but I'm not a guru like some. I can write SQL for anything I need but I couldn't tell you anything about performance tuning my SQL outside of seeks vs scans and the size of a lock.
Understanding the basics of these things isn't really a daunting task and that's why full stack devs aren't paid half a mil a year. But you have to accept at some point that if you're full stack then you're rarely going to be considered an expert in any field. That's not bad though having rounded knowledge is super good.
Companies that underpay fullstack web developers usually don't actually care if their engineers __know__ all that, either. They just want the cheapest, fastest, CRUD app they can demo and ship out ASAP. As a result, these employers fail to recognize (and reward!) the fullstack web developers who do actually __know__ the full stack.
At my last job there was a rockstar web developer engineer who could easily double their compensation by moving to a larger company instead of a startup. My advocacy for them to get a raise or promotion was cast as 'the engineer is complaining again."
The way for full-stack devs to profit most is to work at smaller companies and trade that for equity and seniority.
But this one stood out for me!
> Titles mostly don't matter. Principal Distinguished Staff Lead Engineer from Whatever Company, whatever. What did you do and what did you accomplish. That's all people care about.
To say nothing of a lot of brain.
This is the saddest. One more soul taken by the shrinking of the hacker culture.
I get sick and tired of all the rest of the bullshit, but never with tech and programming itself.
I'm considering just hiring people to do the side projects I wish I had the energy to write the tedious code for.
Another thought that has occurred to me of late: when I started in this field it was "Computers" (capital "C") — a thing really by nerds, for nerds. Increasingly it's the web, mobile. Our "customers" are increasingly not us and so the decisions that would have come so readily to us on how to proceed, what features to implement are instead handed down to us from design, marketing....
So much so that I would have said it is pretty common advice that if you try to turn a hobby you love into a job, there's a good chance you'll end up losing your passion for it.
It's inevitable, now everyone has access to computers and that means the average audience inches ever closer to the average person.
But boy, it feels like crap to make something I'd never use in a million years.
Not that it used to be better: many of my fellow students ended up in business administration. Some might even be architecturing COBOL systems on an IBM mainframe.
The love and passion are still there, but their buried under the needs of my current mediocre job. I need to find a position that will let be get back to the task of building things again, rather than just tweaking scripts and keeping the machinery humming.
They also have another game (the name of which escapes me right now) that is sort of like a bigger version of TIS-100, where you have to write code for microprocessors. I didn't get into that one -- it was a bit less pure and straight to the point compared to TIS-100 or SpaceChem, and one of my favourite things about those games is their fundamental simplicity and transparency -- but I've heard it is good too.
It just doesn’t have much to do with computers and technology in the specific ways that I got enamored with computers and technology. Playing with bare metal stuff at work does. Of course, for someone else it might be the opposite.
For me it’s almost like a graduation or transcending, getting so worked up about the details of computer shit just seems so silly nowadays. It’s actually quite dry and dull when you get down to it. There is a lot more to life.
I really should
When someone says "lisp is the greatest programming language" it's these principles that they refer to, most of which Clojure discards so it can play nice with Java and promote very specialized ways of solving problems in order to best fit a particular niche.
The best way to discover the essence of lisp is to read SICP and learn Scheme.
If you can get by mostly writing Clojure code (either by wrapping the Java libraries that you will use on helpers, or by using third-party libraries), it is a great language, even if in the end it is a very different from any other Lisp (but I'd argue that the changes are for the better, for example first instead of car, thread macros, protocols, immutable data structures). But yeah, for sure Clojure is much more optionated than any other Lisp.
Now, if you need to interop with Java code constantly, yeah, Clojure can be a pain. A good chunk of the code you will write goes to appease the alien structure that is the concept of Class on a FP language.
Clojure has very tangible and definite downsides and tradfeoffs (to name some: weaker REPL, though not as weak as some Schemes. JVM required. Heavy interop reliance), but it has served well as the flagship functional lisp.
https://xkcd.com/323/
Not sure about producfion code though, the values are different
So maybe write drunk, edit sober does work
I can code with a few drinks in me; in fact the activity of coding seems to reduce the amount I drink (I'm a functioning alcoholic).
It's decades since I drank during working hours. In my early career in the City, it was the custom to drink at lunchtime. Those days are passed.
(Even without getting drunk, I've always found it useful to consider a hard decision once analytically and once intuitively, and if I don't agree with myself, think about it some more.)
I thought they were going to go the direction of "he's an asshole" and was ready to accept that, but this particular criticism is actually disturbing. People with strong visions can often appear to be "making it up as they go along," when really they are just subpar communicators.
Short story, I am helping my current company switch from a monolith to service-oriented architecture, and in the process have built a framework for spinning up new fully-deployable services from scratch that gets engineers 90% of the way there (minus the business logic). I have a strong vision for how it works and had a dozen-page RFC accepted by the engineering team for it. Yet there are engineers who think I am making it up as I go (I have been asked this indirectly), without any vision guiding the pieces into place. I have chalked up this feedback to me needing to improve my communication of the vision.
So the post's response of "I realized that he's making it up as he goes along like the rest of us" is disturbing because it makes me realize just how difficult communicating a vision is... if this hero that the poster paid $5k to go see can't even convince one of their fans, what chance do normal people like you and I have of convincing people that we're not making it up as we go?
>EDIT: I realize that I am posting under the assumption that the person's hero does in fact know what he's doing. If he truly is making it up as he goes, the above doesn't apply.
I think people like to believe this because it helps them cope with impostor syndrome, or maybe they think it puts them on even ground with people who do in fact know what they're doing.
Your assessment of why people like to believe this seems spot on.
Most of this stuff comes from students / junior developers, where yes, they probably visit stack overflow every 20 minutes
And it is bad to be a newb? And even for experienced devs to go to stackoverflow regulary ... isn't it productive, to not always reinvent the wheel?
I can solve allmost everything on my own. But if I have a new problem, I assume someone else already had - I would be stupid, to figure it out on my own, when I could get a working solution in 5 min googling.
But I actually programm without internet connection most of the time, as I like being outside, away from noise (and wifi)
That said, stack overflow can be a great source and I’ve written plenty of code with a comment pointing to a SO link to further explain a pattern or snippet for a future reader.
Yeah sure. A stupid programmer will remain a stupid programmer, even if he reaches a certain productivity by living off of stackoverflow ...
I do see two kind of people doing that. One group learns from the code in order to become better, and can use it over and over to be more efficient. The other group doesn't care how it works and just wants to have a snippet that works.
The second group usually misses a curiosity, of which the effects show up in many more places than just copy pasting from stack overflow. They also tend to have a flatter learning curve. I don't want to generalize, but in this group you will encounter people who don't care about the difference between a list and a set, or think that code works when it compiles. In both cases the juniors know very little, but one grows and the other one doesn't (or less)
There is space for both in the world, but I prefer the first group in my team.
The foundation tends to be pretty simple, deeply held, and unchanging, while the higher levels are increasingly fluid and specialized. The higher you get on this stack, the more "making it up as you go along" it becomes, but every improvised part is perched on something more stable.
They key to "knowing what you're doing" is organizing this hierarchy well, having the right supports in place to successfully guide improvisation and course-correction while steadily fortifying the foundation.
I take this really just to mean "everyone has faults".
People often idealize heroes and think of them as beyond human. If you do that and met your hero then your illusion will often be shattered. But the problem is just that you were putting them on an unreasonable pedestal.
Of course some people are frauds and some people have no idea what they are doing but manage to make people think they do. But I didn't read this as being one of those situations. Just someone they saw as beyond human being only human.
Then there's the times where you think you know exactly what you're doing and after going down a road you realize it's the wrong way. Failing to learn and see the signs and make the embarrassing declaration that you got lost and need to turn around is never good. But some people just keep driving. It's hard though when there's a big line of cars behind you that think you actually know where you are headed.
Sometimes it's a hybrid of knowing what you are doing but not knowing the implementation specifics. You know you need to connect high-level pieces A, B, and C with specific constraints, but it won't be until you get into the low-level implementation that you'll know if it is indeed possible. I think that's an example of both having a vision and also improvising as you go.
I am concerned about how to effectively communicate visions to people, because it gets everyone rowing in the same direction. If nobody thinks that you have a vision, when you do, there is no reason they should choose your direction vs just do their own thing.
Maybe it is communication related. Does everyone know that this is the way they should do something? But they still don't? Have you created docs and edicts around these areas? Have you been assertive in code reviews? Have you been proactive and requested design sessions before a lot of work was done?
Has a decision been formally communicated? I see this step not happening enough, people are hesitant to be authoritative after a discussion on architectural concerns. If you are the lead, that needs to happen.
Most of the time it's simply a case of them not knowing how to do it. People are afraid to show their lack of skill and knowledge and ask for help. They get deadline pressure and deliver their default way.
Have you provided a feature or cut through the system that shows this vision for people to follow? Maybe example code, resources on the web that go very deep into the ideas and tactics? Have you paired with them to help them get started or get over obstacles. Perhaps pair your most senior person with juniors for a while to get them on the same page and capable with this vision.
For myself as an opinionated person in a devops role, the vision that I try to communicate to my colleagues is mostly broad principles like configuration as code, helping people help themselves, consolidation of systems, and then some more pointed specifics like don't touch prod, don't make changes without a consensus, start by understanding why it's the way it is before changing it, etc.
I used to have visions. Now I have collaborative design discussions driven by some starting designs. I found that if people don't contribute to the overall design then they have little impetus to actually understand it. This tends to lead to a better design and a more engaged team so a win on all counts.
Nothing if you're good at it. But if you're hoping to learn something from someone, it is pretty disappointing. How to make it up as you go along is far less teachable.
How do you distinguish between what you do and "making it up as you go along"?
I'm guessing that this was based on first-hand experience building such services and witnessing engineers struggle getting new services up. And not so much that you've had specific training or past experience in developing bootstrapping frameworks. This would be my definition of making it up as you go and is great way to do it. Another way is learning how to make bootstrapping frameworks and applying it wherever you can which doesn't go as well.
(I work at Red Hat, and my programming heroes are also my colleagues.)
I "know" guy who's conference speaker, so he knows other conference speakers, drinks vodka with them and so on.
He says there's significant amount of bullshit aka things that work nice on slides, things that only work cool in theory, but in practice they arent as great
I think that's what OP meant
In sports terms it would be something like a baseball pitcher being able to throw a great curveball, a great fastball, and an all right slider, and knowing roughly what situations to use them in. There will still be a high degree of randomness and mistakes will be made.
I would much rather work with people who have a good track record of making it up as they go as opposed to people coming in with a fixed idea of how something should happen and are more likely to misapply whatever lessons led to those views (probably someone elses anyway).
and the wine. more wine.
Yes, something is wrong. But it could be many things. Here is how you can find out:
1. Is the thing that's broken a bug in your code? Then it's your fault, so fix it. This means you need better testing too, and maybe a redesign to resist failures. Try to get alerts at 9am in dev so that they don't come in at 2am from production.
2. Is the thing that's broken a server thing that Ops is supposed to deal with? Probably you should quit. You can also work with Ops to redesign the server stuff to be something less prone to failure. Often Ops can't do this themselves because they don't know enough about how your apps work. Go talk to them, help them out. Or quit.
3. Is the thing that's broken a false alarm, or not important? Quit. Or work with Ops to create better alarms and tests. Ops doesn't know your app, so you need to help them craft the SLIs and SLOs.
4. Did Ops create all these alerts themselves without your involvement? Quit. Or take ownership of the tests and alerts for your apps.
5. Is it a huge slog to try to figure out how the alerting works, to work with Ops to make changes, to add tests, or to figure out what's broken or not and troubleshoot it? Definitely quit.
Sometimes fixing the problem will require special access to Production which you don't have, or even a specific role with that extra bit of initiative.
Otherwise i agree 100%.
If it's unfixable, that's when you quit
Operation, and on-call staff fixes broken systems just enough, that they will work until 8:00AM when the developer is back at work.
Just this week I talked to a developer, and he asked if I could switch the phone numbers, so issues would get routed to him first. My question: Why? You can't really do much without me being awake as well, so maybe I get the first call, and I call you... IF I need to?
Maybe... none of this applies to people who own meaningful portions of the companies they work for.
Just get yourself a drawing tablet and some whiteboard software like Openboard (http://openboard.ch/index.en.html).
> Good people write shitty code. Smart people write shitty code. Good coders and good engineers write shitty code. Don't let code quality be a dependent variable on your self worth.
That's like saying that eminent book authors write shitty books. Sounds like an excuse.
> I've become what I've always hated: someone who works in tech in a career but avoid tech in real life. Maybe that comes with being old.
It's all about finding the right project. REST + CRUD shit gets exhausting after 5 years. There's an entire world of excitement outside of REST + CRUD.
Full stack compresses two jobs into one. It's purely for cost-savings. They're paid so little because companies revert to "well, you can still only do 8 hours, so you do half as much of each", but really that's just them trying to weasel out of paying for knowledge. They also blur the lines by putting full stack along-side other devs, even though the other devs may not have invested the same time to gain as much knowledge as full stack.
When you take a full stack job, you undervalue your knowledge (and the time invested) and are selling it for roughly half of what it's worth.
My experience is that at some scale it works out okay, but beyond a certain point it just falls flat for most. We deal with insanely talented developers, who will trash a database, because it don't understand how it works. Talented JavaScript developers, who don't really understand how HTTP works... or load balancers, or caching... or webservers. Sometimes you get these fantastic software machines as deliverables, complex, you can't monitor them, or configure much, and the it just implements a basic feature of HA-Proxy or Apache, but badly.
My point is that they should be paid poorly, because they fail to be excellent at every part of their job, but rather than: Yes, this should in most cases not even be a job title. If you find someone who can do all of this well, you almost can't overpay, but are you really sure that you want to tie everything up on one person anyway?
Not having to wait for some other engineer to make the backends made us a lot more efficient. It definitely was rewarding to be able to complete products end-to-end.
Hiring standards and pay were the same as for any engineer, at least in FAANG.
[0] Yeah, occasionally we had to optimize some SQL queries or whatever but we're competent engineers, we can figure it out even if it's not what we do every day.
This is 100% accurate in my experience too, and it's also true in the other way around: "full-stack" means backend developer who can put a basic SPA using React/Vue.
From the frontend perspective: they call themselves full-stacks for knowing how to spin up a NodeJS HTTP Server powered by Express with MongoDB inserting JSON in the database. But they are missing:
- AWS/cloud computing: not necessarily creating the infrastructure (although that's a must on more senior levels), but how to orchestrate the different components together.
- databases: why SQL/NoSQL, beyond basic SELECTs, knowing how to properly add indexes, debug why queries are slow, modeling, understanding locks implications and transaction levels, and so on.
- tooling: how to set up a bundler, linter and formatter, testing, CI/CD. This overlaps a bit with the responsibilities of the DevOps engineer, but a full-stack should know at least on intermediate level all of those things. I can't say how many times I've seen "senior full-stacks" that had no clue about how webpack worked at all.
From the backend perspective: they call themselves full-stacks for knowing how to spin up a React/Vue app that does basic CRUD operations using forms, powered by a UI framework like Material UI. But they are missing:
- CSS: most will find CSS hard/annoying and won't bother understanding at all how it works even on a fundamental level, will defer to hacks most of the time to make things work, especially when it comes to adjusting for edge cases like responsive design or cross-browser support.
- the DOM: normally they don't understand it at all, or to a very limited extent.
- Web vitals: how to measure and makes things faster and performant—not really including here overly optimized, but just making sure your app is 60fps or close to that most of the time. Usually when things get slow either on the network side or in the app itself, those engineers will blame is the framework/library, not their misusage of it.
--
Those lists are definitely non-exhaustive, as I didn't even mention more advanced stuff like protocols (how HTTP works? most can't answer), caching, etc etc, but you can get the point I'm trying to make:
The problem with the term full-stack is that only very few engineers really are sufficiently great on both sides of the stack and could say that they mastered both, simply because there's just too much to learn! Frontend has become so much more complex with SPAs compared when it was about rendering static HTML with some CSS and basic behavior with jQuery. Same for backend with the advent of cloud computing and several types of databases.
I've been coding professionally for a decade and I've met only a single engineer that I'd consider him full-stack (he checked all those boxes I mentioned and more). I think I would also include myself, because I spent 50% of my career spent as a front-end engineer, became senior, then I transitioned to back-end engineering because it pays the same or more and it's less stressful (for most of the regular companies that most of us work at). My current title is "principal full stack engineer", but in practice I only do backend/devops, I don't actively code front-end but I keep up with the industry by following the new trends and testing things here and there in personal projects.
Ultimately, I believe for being a full-stack engineer you have to be first a front-end (or back-end engineer) then learn the other, what we have today is most people doing the same from the very beginning of their careers and they either go deep on a single one or in none of them.
The front or backend bias you and your parent's comment talk about are team specific things so you don't give a hard front-end task to someone who is biased towards the backend. That still means they can take the less difficult tickets.
You can replace full stack for your example with "extremely good/talented/gifted engineer" and I'm almost sure it has nothing to do with the full stack label because it's the only example in a decade you've found.
But also the jobs that they get feed back into what they call themselves. So even if that's your example, it isn't how the business defines it, which IMO is ultimately why it's just a cost savings label to get people to work harder for similar amounts of pay as front or backend people.
You can make doctor level salary at the ceiling if you move to a FAANG as a full stack dev.
The fact that boot camps even exist shows that it’s not that difficult of a job.
Other industries boot camps don’t even exist.
Full-stack developer knows some frontend, some backend, some sql. They are paid good money because they are convenient, not for their knowledge. A dev who does only one thing knows way more about it that a team of full-stack devs.
Full-stack devs earn a lot and will probably earn only more in the future.
This is mostly a result of tech advancements like cloud infrastructure, tools etc that takes all the hardest things from you - like managing a DB, implementing security, managing infrastructure, deployments etc.
You don't need deep experts because of it, generalists are perfect for quickly shipping new features.
This got me and somehow bloody true.
Maybe he is on to something.
Highly recommend a journalism class at local community college.
It does help but I am not sure I would describe _my_ education as a panacea.
The main reason it was good was because it helps frame how you think of writing,
The most important things go first. Statement of fact, then you go into what the implications are, then you start introducing less and less relevant elements.
when you’re writing you keep the 5 “W’s” in mind, make sure you answer them. (Who what where when why), for instructive documentation you add: How.
Obviously an education bakes this into you in a better way than I can convey here.
What I learned is probably only decent for writing overviews.
Personally I find structure to be the biggest bottleneck/difficulty when making documentation.
What do others normally struggle with that don’t have this education?
Learning how to write proper instructions is the gateway to proper documentation.
Two reasons: 1. everyone calls themselves this these days, and 2. they are often quite weak in each of those parts of the “full stack”