[HN Gopher] Drunk Post: Things I've Learned as a Sr Engineer
___________________________________________________________________
Drunk Post: Things I've Learned as a Sr Engineer
Author : tosh
Score : 691 points
Date : 2021-05-30 13:55 UTC (9 hours ago)
(HTM) web link (old.reddit.com)
(TXT) w3m dump (old.reddit.com)
| erdo wrote:
| > 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.
|
| Couldn't agree more
| dehrmann wrote:
| > Algorithms and data strictures are important--to a point
|
| For me, 90% of day-to-day algorithms use is not writing O(nm) or
| O(n^2) code, and knowing which data structures to use to avoid it
| (usually a hashtable, occasionally a heap or balanced tree).
| dmlittle wrote:
| It all depends on your use case. If your input is bound to a
| small N, I'll take the simplest to understand implementation
| regardless of algorithmic complexity. Future you and other
| people will thank you later.
| dehrmann wrote:
| If small-bound is <20 and likely to never be >50, yes.
| Otherwise, be careful; future people will _not_ thank you for
| that timebomb.
| jedberg wrote:
| If you're really cool, you make it throw an error if n > 50
| along with a comment explaining why, or at the very least
| leave a comment saying "this is not the optimal algorithm
| and will break if N gets much bigger than 50".
| anyfoo wrote:
| I don't know why you have been downvoted, you do have a
| point. Algorithms are tailored towards specific purposes. If
| you for example have something that runs with an n of about
| 5, and it's not in a hot path, the clear concise solution may
| well be better. Besides, with small n there is more to the
| cost of an algorithm than just its asymptotic growth.
|
| However, to the point of the person you've replied to: It's
| good to know that stuff to be able to assess the situation in
| the first place.
| cortesoft wrote:
| > The greatest programming language ever is lisp. I should learn
| lisp.
|
| I really should
| tomcam wrote:
| Damnit me too
| sundvor wrote:
| Do it, if only to find Clojure.
| creamytaco wrote:
| 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.
| wilsonthewhale wrote:
| 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.
| AlexCoventry wrote:
| Which of Lisp's philosophies and principles does Clojure
| violate?
| adamnemecek wrote:
| What principles are these?
| m45t3r wrote:
| 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.
| giraffe333 wrote:
| Adding on to the thoughts about everyone writing terrible code
| sometimes, there is also "terrible code makes lots of money".
|
| Source: over 20 years doing software dev at various companies
| with terrible code that makes millions. Happily my current job
| has really great code (imho).
| ecshafer wrote:
| How often do we see a collapsed and failed start up where
| people will say "Wow there was some good tech at that company".
| Good code and cool code exist on an independent axis as good
| business plans.
| sharken wrote:
| > 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.
|
| Otherwise i agree 100%.
| sangnoir wrote:
| > Sometimes fixing the problem will require special access to
| Production which you don't have
|
| If it's unfixable, that's when you quit
| TameAntelope wrote:
| 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.
| obstacle1 wrote:
| 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.
| mrweasel wrote:
| 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?
| frereubu wrote:
| 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.
| gautamnarula wrote:
| Reminds me of Hemingway's "Write drunk, edit sober."
| edoceo wrote:
| Not for code tho. I've never seen booze help make good code
| hutzlibu wrote:
| 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.
| tsimionescu wrote:
| There was an old xkcd about this, though I will admit I
| have never experienced this:
|
| https://xkcd.com/323/
| topkai22 wrote:
| 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
| edoceo wrote:
| I'll admit to banging out v0.0.0 code with a buzz. Mostly
| it's comments and shit-code as documentation. Sober eyes
| and test cases before production.
|
| So maybe write drunk, edit sober does work
| rewgs wrote:
| I find "write sober, review drunk" to be much better advice.
| rcpt wrote:
| https://en.wikipedia.org/wiki/In_vino_veritas Is the phrase.
| Useful if you want to appear cultured at a company party.
| frereubu wrote:
| 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.
| Demeno wrote:
| In Hebrew we have "nkns yyn - yts svd", loosely translates to
| "Wine entered - secret came out".
| daenz wrote:
| >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.
| toss1 wrote:
| 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"?
| gher-shyu3i wrote:
| The problem is idealizing such people in the first place. Sure,
| they may have had incredible achievements, but they're humans
| at the end of the day.
| thisismyswamp wrote:
| 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!
| karmakaze wrote:
| > 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.
| booleandilemma wrote:
| 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.
| WJW wrote:
| 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.
| andreilys wrote:
| Even worst is the meme that "programming is just copy+pasting
| from stack overflow"
| user_50123890 wrote:
| Because good senior programmers are rare (as can be
| observed if you post a job listing).
|
| Most of this stuff comes from students / junior developers,
| where yes, they probably visit stack overflow every 20
| minutes
| MikeDelta wrote:
| They should try programming on an airplane or without
| internet connection. For some the productivity drops to
| zero without stack overflow.
| convolvatron wrote:
| 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.
| emidln wrote:
| 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?
| hutzlibu wrote:
| "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)
| mortenjorck wrote:
| 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.
| the-pigeon wrote:
| It really depends.
|
| 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.
| bitexploder wrote:
| 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.
| vlunkr wrote:
| 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.
| swader999 wrote:
| 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.
| daenz wrote:
| 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.
| marcinzm wrote:
| >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.
| mikepurvis wrote:
| 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.
| swader999 wrote:
| 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.
| tester756 wrote:
| I have different take on this
|
| 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
| dehrmann wrote:
| 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.
| [deleted]
| rwmj wrote:
| Also which "hero" is charging 5k for courses and what form does
| the course take?
|
| (I work at Red Hat, and my programming heroes are also my
| colleagues.)
| hprotagonist wrote:
| i see nothing i disagree with here.
|
| so either i'm doing OK, or we're both fucked...
| jeffrallen wrote:
| Or you're drunk too.
| brundolf wrote:
| > It's not important to do what I like. It's more important to do
| what I don't hate.
|
| This one has started to dawn on me. I'm never going to love my
| job as much as I love my personal projects, so a job that I don't
| get very excited about but doesn't drain my energy is better than
| one that I get somewhat excited about but does drain my energy
| (not that it's impossible to have both, but it's rare)
| sbarre wrote:
| I made this exact choice about 5 years ago and my life has
| dramatically improved.
| fmakunbound wrote:
| > The older I get, the more I appreciate dynamic languages. Fuck,
| I said it. Fight me.
|
| I see this in myself also. Static typing is such a fever at work
| especially amongst juniors and mids. Sometimes it's almost as if
| they believe object types will spontaneously change at runtime,
| unpredictability.
| anyfoo wrote:
| But that's exactly the point. It is too easy to introduce a
| code change that effectively will unpredictably (because it was
| unintended) change a type to something unexpected. And then
| blow up much later in spectacular ways.
|
| Try writing something asynchronous in python with futures and
| complex nested data types. See how long you enjoy being told
| that you're trying to look up a key in something that doesn't
| seem to be a dictionary before you switch to static typing with
| mypy, and can spend your energy on solving the real problems.
|
| I've been programming for way over 20 years, and I do not
| understand how people enjoy debugging something that the
| compiler would just tell them.
| fmakunbound wrote:
| I get all that, however I am saying that they're being
| superstitious about it. I've been programming at least 20
| years and thoroughly love programming in a dynamic language.
| My preferred being Common Lisp.
| dijit wrote:
| I'm operations focused (traditionally Sysadmin but I can code
| to a decent degree and do professionally) but I suspect we've
| all been bitten by something being inferred we didn't expect.
|
| YAML interpreting NO (Norway's country code) as false being the
| most immediately obvious.
|
| Bash has a lot of these kinds of issues too, I don't remember
| all the rules so I quote everything to be safe and still get
| bitten by variable expansion sometimes.
|
| Types that change depending on what the value is: that scares
| me.
| dontbeabill wrote:
| the journey is the reward.
|
| and the wine. more wine.
| soheil wrote:
| He sounds like me when I'm extremely sober, so surprising to see
| how unoffensive and tame people's "secret thoughts" are, well at
| least the ones that get massive upvotes on reddit.
| vageli wrote:
| > 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.
| jjice wrote:
| > 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.
| mancerayder wrote:
| 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.
| routerl wrote:
| > 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" and "inform" are such closely
| related words.
|
| [1] http://worrydream.com/refs/
|
| [2] http://worrydream.com/refs/Ong%20-%20The%20Writer's%20Aud
| ien...
| Tempest1981 wrote:
| I've seen lack-of-documentation worn as a badge of honor. "I'm
| moving so fast, I can't waste my time on documentation. That's
| the next guys problem."
|
| And management is usually/always ok with this short-term
| optimization.
| b3morales wrote:
| 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.
| Jiocus wrote:
| That's a useful take,
|
| _Code says what is done. Docs says why_
| withinboredom wrote:
| 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.
| dijit wrote:
| But there are circumstances where documentation would be
| outdated before it is finished.
|
| Trying to write ops documentation on an unfinished project
| can be this way.
| hnedeotes wrote:
| 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.
| jtouri wrote:
| 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
| ljm wrote:
| 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?
| dehrmann wrote:
| 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.
| tobesure wrote:
| 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.
| ChrisMarshallNY wrote:
| I just use headerdoc-type stuff. Been doing it for decades.
|
| 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.
| GordonS wrote:
| 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...
| ChrisMarshallNY wrote:
| Absolutely. I do those, as well. Here's a rather more
| intense example: https://riftvalleysoftware.com/work/open-
| source-projects/#ba...
|
| 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.
| GordonS wrote:
| Ah nice, it's refreshing to see that level of
| documentation for an OSS project, even if it started as a
| commercial project.
|
| Totally agree about not having too much documentation -
| sometimes outdated documentations is worse than no
| documentation at all.
| NortySpock wrote:
| The first thing to learn is that there are four types of
| documentation:
|
| 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...
| mikepurvis wrote:
| 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.
| 0xbadcafebee wrote:
| 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.
| nautilus12 wrote:
| Seriously. Fuck pandas. And fuck dark for encouraging it.
| nautilus12 wrote:
| Dask
| dehrmann wrote:
| 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).
| brundolf wrote:
| 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)
| devpbrilius wrote:
| Rather be sober, guy at courts.
| steindavidb wrote:
| > 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.
| elliotec wrote:
| Can you elaborate on that? Why journalism in particular? Have
| you done this? Are you better at docs?
| dijit wrote:
| 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?
| chx wrote:
| Whiteboard paint exists.
| dmlittle wrote:
| 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.
| eyan wrote:
| > If I didn't learn something from the junior engineer or intern
| this past month, I wasn't paying attention.
|
| Amen! Not just junior engineers. PMs, analysts, testers. We all
| have a lot to learn from the rest of the team!
| odiroot wrote:
| > The older I get, the more I appreciate dynamic languages. Fuck,
| I said it. Fight me.
|
| The other ones are quite obvious but this is the one that really
| resonated with me. People, with experience, tend to get more
| pragmatic and less "academic".
| 734129837261 wrote:
| I keep getting downvoted on Reddit for stating that I
| personally hate TypeScript to the max. It ruined the beauty of
| JavaScript (once you know it, anyway, I understand there are
| difficulties for JS-novices) and I honest to goodness 100% do
| not EVER find myself thinking: "Gosh, thanks TypeScript!" - on
| the contrary, it's always: "For fuck's sake you stupid POS
| TypeScript, you're wasting my time for no benefit at all."
|
| Strong-typed languages (especially in the damn browser) make no
| sense to me. It's not like we need to manage memory or
| anything.
|
| 20+ Years of experience here, and I hate TS with the passion of
| a thousand suns.
| gentleman11 wrote:
| It might be your strong wording that people are responding to
| jghn wrote:
| As I got older the more I appreciated static typing and
| expressive type systems. To each their own.
| anyfoo wrote:
| Pragmatic for me is knowing what's wrong at compile time, and
| not being told much much later at runtime that I nested this
| array in a dictionary in an array wrong, or that my string is
| an integer.
|
| I got older, stopped using python for exactly the reasons above
| (I just really felt that it was wasting my time for trivial
| reasons), and found mypy which made it bearable again.
| humbleMouse wrote:
| Groovy is a dynamic language that runs in the JVM, it lets
| you put @CompileStatic at the top of every class.
|
| I believe typescript also has options for compiling
| statically.
| BigJono wrote:
| Yeah, I'd be on board with that if 99% of the people talking
| about typed languages at the moment weren't using Typescript
| for use cases where you literally get instant feedback from
| hot reloading as you code.
|
| Every time I see an example of a bug that TS would solve,
| it's something that I routinely find in 2 seconds by looking
| 10 degrees to the left at my second monitor and noticing the
| screen is white and there's some red text in the dev tools.
| "Compile time" doesn't mean anything if it consistently
| happens 0.5s before "run time".
| yakshaving_jgt wrote:
| Yeah, the funny thing for me is that I run my business on
| Haskell exactly for the sake of pragmatism.
|
| The last time I had a job was on a Clojure team, and that team
| has since abandoned Clojure and some of my former colleagues
| have come to me and essentially said that they got tired of
| fighting with runtime errors.
| mastrsushi wrote:
| >I'll just pick up a new job in 2 weeks
|
| hehe, right
| ggregoire wrote:
| > The older I get, the more I appreciate dynamic languages.
|
| Exactly the opposite for me. I just can't stand hovering a
| variable or a parameter and not getting its exact type, or typing
| "." after a variable and not having my editor gives me all the
| available methods on that variable, or running my code just to
| discover that it instantly crashes because I made a typo or
| forgot an argument or passed the wrong argument or tried to call
| a method that doesn't exist on that variable or whatever other
| issues that happens only with dynamic languages. What a waste of
| my time.
| zug_zug wrote:
| Agreed. Try going from "I think this is a callback that returns
| a promise which can return a string or an int?" to "The
| compiler/IDE are telling me this future can only return an int
| and won't let me advance until I make my code comply"
| Siira wrote:
| I started programming with .Net languages via Visual Studio
| (which is quite a good IDE), and I disliked dynamic languages
| exactly for the reasons you list. But nowadays I mostly prefer
| dynamic, optionally typed languages ala Julia.
|
| Typing a '.' and seeing the members is very nice, except when
| the type is not concrete and it's not clear what type is
| actually being returned. Then you'd have to do trial-and-error
| using a slow compile cycle. In a dynamic language like lisp,
| you could just `(inspect x)`. In Python, you can just `embed()`
| and run, e.g., `x.__dict__`.
|
| The IDE telling you about syntax errors and non-existent
| functions etc is very nice, except when you use macros and
| meta-programming and now your stupid IDE won't just shut up (I
| have this problem even with Python in VSCode).
| anyfoo wrote:
| As I said in another ranty response in this thread, I do not
| understand how people enjoy spending time debugging trivial
| issues, that even a simple static type system would just plain
| tell them at compile time.
| 3pt14159 wrote:
| I've been programming for over 20 years too, and I like
| dynamic languages. I like them a lot more when they're
| properly tested and well architected, but even the tire fire
| codebases are at least debuggable. The compiled stuff helps
| with types catching the trivial bugs, yes, but it's way too
| complicated to quickly debug things like seg faults. Dynamic
| languages let you introspect and modify things way more
| easily, and this makes things like fakes and mocks for
| testing way easier. It makes debugging easier. And not having
| to wait an hour for something to compile is nice.
|
| That said, I love the speed of compiled languages. I once
| converted a simulation from Python to Cython and saw a 10000x
| performance boost because of CPU caches and all that. Usually
| the gains are closer to 10x to 20x, but in some rare moments
| it's like a rocket ship vs a hang glider.
| anyfoo wrote:
| EDIT: Reading again, I think you are comparing interpreted
| with compiled languages, not so much static with dynamic
| type systems.
|
| Seg faults are a prime argument _for_ static typing. The
| more static and stricter the type system, the less things
| like seg faults can even happen. Compare Rust to C (both
| are static, but one more than the other), and at the
| extreme end handwritten assembly ( _extremely_ dynamic).
| Those are languages used by kernel developers, where errant
| memory accesses of all kinds are a constant concern.
|
| I don't know why dynamic languages would make introspecting
| things easier, or debugging in general. I agree that
| mocking can be easier with dynamic types. Compilation
| rarely takes long nowadays (incrementally it's usually just
| a few seconds), so the time saved in knowing that the code
| is still correct at least within the confines of the type
| system is well worth it.
| Gibbon1 wrote:
| Comment about seg faults. You can with a little upfront
| work trap them and pull enough information off the stack
| to know where that happened.
|
| I find that 90% of the time I can figure it out via
| inspection of the offending code.
|
| Opinion: The class of bugs that cause seg faults in some
| languages cause run time errors in other languages.
| belorn wrote:
| As an kernel developer, would you want to take some of
| the many shell scripts that the kernel has and rewrite
| them in C?
|
| Different tools for different purpose. Unless there
| ecosystem was really designed for it, I would not write a
| driver in a dynamic language. At the same time, I would
| prefer not to write all the bootstrap scripts during
| booting in C. If all I am doing is calling other
| programs, I use shell. If all I am doing is calling a
| bunch of low level system calls in a restricted
| environment I would use C. If I am doing a bunch of
| string editing, process flow management, data compiling
| with some calls to external programs, I would use a
| dynamic langue like Python.
|
| I want add a personal opinion in regard to C. Every
| function gives out an return code which is a kind of
| "type" that does not get enforced by the compiler. The
| return code is defined by the manual page and it is up to
| the programmer to catch it and react correctly to it. If
| the wrong code occur and the program explode during
| runtime its the fault of the programmer for not write a
| program that manage the return code. I would claim that
| the wast majority of crashes that occur in programs
| written in C is because programmers failed to realize the
| full list of possible return codes and what they mean.
| Here I do prefer dynamic languages because they usually
| do not leave it up to the manual to defined what return
| code -42 means compared to -41, and debugging errors when
| the errors themselves have class names and inheritance
| tend to be a bit easier in my experience.
| anyfoo wrote:
| The kernel itself does not consist of any shell scripts.
| It may have them for building the kernel, but just like
| the shell scripts at boot, the problems solved there are
| much simpler (mostly call compiler and linker on a set of
| files). So I agree: For simple high level problems a
| dynamic language is sufficient.
|
| As to your second paragraph, I do agree that C has a
| _vastly_ insufficient type system from the 70s (even
| though I think better type systems were already available
| at the time, but the inventors of C might not have known
| or cared about that). Rust solves the problem you
| described, and what you complain about is actually that
| errors in C tend to be represented _not statically
| enough_.
| sanderjd wrote:
| What's a seg fault? I jest, but static languages have come
| incredibly far since C++ (where they are already less
| common than in C) and I truly haven't dealt with a
| segmentation fault in the past many years working with
| static languages.
| repExpMon wrote:
| > but it's way too complicated to quickly debug things like
| seg faults
|
| I know you've listed the common argument for static vs
| dynamic (dynamic -> so fast to code but slow to run, static
| -> way too complicated)but after a decade in SE I still
| have yet to see some good evidence of this.
|
| Yes some static languages (like Java) will make developing
| certain things slower vs JS but is Java a good statically
| typed language ? Maybe these statements are "true" today
| with the current implementation of one or the other but
| there are a lot of languages that I just can't see getting
| in the way.
|
| A new example of this: Kotlin and Swift are statically
| typed and I would love love to see where it slows these
| mythical developers that are so fast in a dynamic language
| but would be slowed down using them. There's obviously
| going to be a cost for the actual compile time but that
| should be minimal.
|
| Unfortunately I'm starting to believe that this is just
| another case of certain developers are used to certain
| languages.
|
| The trend of the JS move to TS also points to this.
| Basically JS looks very similar to Kotlin and Swift (TS is
| basically identical).
|
| To look at your specifics > Dynamic languages let you
| introspect and modify things way more easily, and this
| makes things like fakes and mocks for testing way easier.
| It makes debugging easier. And not having to wait an hour
| for something to compile is nice.
|
| > Dynamic languages let you introspect and modify things
| way more easily
|
| In what way ?
|
| > and this makes things like fakes and mocks for testing
| way easier
|
| Fwiw this is what that fake/mocks look like for a static
| language `val x = mock<User>()`
|
| To be fair that's using a library and maybe that's part of
| your criteria ?
|
| > It makes debugging easier
|
| ? how, I can see the argument for the other way (one less
| thing the developer has to worry about - typing issues) but
| how is dynamic easier to debug ?
|
| > having to wait an hour for something to compile is nice
|
| Completely Fair. Now whether or not the thing you're
| working on would take an hour to compile I highly doubt. If
| you're working on a project that would hypothetically take
| an hour to compile then I really hope it's not written in a
| dynamic language.
|
| Not trying to pick on you at all, I believe a lot of
| developers would agree with you but I'm starting to think
| that there are developers that are just used to one or the
| other. I have to point out that I could be thinking this
| way with respect to statically typed languages but I really
| have a hard time seeing this point (as I would be if I was
| falling into the same trap I'm "accusing" you of).
| yarcob wrote:
| As a Swift dev, the reason why it slows me down is that I
| often end up fighting the type system.
|
| I start with a concept, design my data structures on the
| whiteboard in a way that makes sense, then I try to code
| it and because of some detail in the type system it
| doesn't work, and I end up spending huge amounts of times
| wondering how to translate my concept into code.
|
| I don't have that issue in other languages.
|
| Also, the Swift compiler is really really slow.
| anyfoo wrote:
| Read what they wrote again, but this time replace
| "static" with "compiled" and "dynamic" with
| "interpreted", and suddenly it made sense to me.
|
| It's true that overall, compiled languages tend to be
| more static, and interpreted languages more dynamic (and
| there are good reasons for why they end up that way
| besides mere convention), but nevertheless that's not
| what this discussion is about.
| durandal1 wrote:
| You're a python dev and never had to investigate a segfault
| in some buggy C module?
| wirrbel wrote:
| I mean by now it should be clear to everyone that there are
| certain trade-offs in the choice dynamic vs static typing.
|
| I do like clarity of static type declarations, also the
| absence of weird polymorphism like functions returning a
| number or al ist of numbers depending on their parameters,
| etc.
|
| But then, many statically typed code bases are just tested
| abysmally. It is as if the type signatures would constitute
| proper tests. I realise that you don't need to write as many
| tests in a statically typed setting, but in many cases - and
| esp. in underpowered type systems - the types won't test the
| program's logic.
| anyfoo wrote:
| You _do_ need to write less tests with a static language.
| The types in your program are proof that your program is
| correct within the confines of the type system (literally,
| even in the mathematical sense).
|
| The stronger the type system, the more properties can be
| proven through it (at the extreme end there are,
| unfortunately not Turing complete, languages where you can
| prove every single property--those are more used as theorem
| solvers however).
|
| Back to "common" statically typed languages, there is still
| heaps and loads to test, as you say. Not writing those
| tests is not really the fault of the language...
| dmlittle wrote:
| I think it depends on what you're doing. The author of the
| the Reddit post mentioned he's primarily working with data
| systems. I can see the appeal of someone running quick,
| ephemeral data analysis not wanting to deal with static
| typing. But for long term use cases the static typing guard
| rails is definitely nice.
| repExpMon wrote:
| > I can see the appeal of someone running quick, ephemeral
| data analysis not wanting to deal with static typing
|
| I've seen and heard this, (Data science field definitely
| loves their Python and numpy) but I really believe the
| common problem of non-reproducible research is partly due
| to the language choice (and probably more to the root cause
| - this sentiment in research).
| diob wrote:
| Yeah, I loved it when I started because I could easily try
| things out in JavaScript. Eventually I've come to love
| Typescript because I don't waste time on dumb things anymore.
| eloff wrote:
| > Exactly the opposite for me.
|
| Yeah, same here. I started my career as a huge dynamic
| languages fan, and Python was my favourite language for over a
| decade.
|
| But now, after 20 years, I appreciate a static language with
| proper IDE support and code completion. Offload the work to the
| computer, that's what we do for a living after all.
|
| However, after spending a year working in Rust, I think this
| can be taken too far. The safety guarantees in Rust are
| amazing, but the overhead for contorting programs to a form the
| borrow checker will accept, and the mental overhead related to
| async/await compared to goroutines is too much.
|
| My favourite language is now Go, and I find it strikes a good
| balance between static checks and productivity. Rust is still a
| more elegant language in many ways with things like generics
| and iterators and their enum types (algebraic types I think is
| the term?) and zero-overhead abstractions and clean error
| handling. Go feels a little hacky by comparison. But it's
| simple and way more productive for me personally, so I prefer
| it.
|
| Interestingly Evan Wallace (constexpr here on HN) implemented
| esbuild in Rust initially, and switched to Go and stayed with
| it for much the same reasons, but also noted that the Go
| version performed better:
| https://news.ycombinator.com/item?id=22336284
|
| > But at a high-level, Go was much more enjoyable to work with.
| This is a side project and it has to be fun for me to work on
| it. The Rust version was actively un-fun for me, both because
| of all of the workarounds that got in the way and because of
| the extremely slow compile times.
|
| After a year of working with Rust and switching back to Go, I
| second this. I'm enjoying programming again and finding it
| easier to put in long hours.
| 734129837261 wrote:
| I've been doing TypeScript for 4+ years and been a web
| developer for 20+ years. And I experience literally zero
| benefit from TypeScript. Never has it given me anything useful.
| To me, it's a massive pain in the ass that slows down myself
| and my team, even if they think it doesn't. They just don't
| know JavaScript or have shitty quality of code to begin with.
|
| That, and TypeScript generics can get so freaking complex that
| the code does NOT become simple to read at alllllll. It's a
| massive waste of time.
|
| Also read: https://medium.com/javascript-scene/the-typescript-
| tax-132ff...
| tomnipotent wrote:
| TypeScript, PHP, and Python have support for typing and the
| commiserate IDE benefits, and I'd imagine these languages
| account for a super majority of software written in dynamic
| languages.
| anyfoo wrote:
| Yes, I've started using python again with mypy static typing.
| I can hardly still call it a "dynamically" typed language if
| I do that, though.
| tomnipotent wrote:
| The type hints are still just type hints, and have no
| influence on run time. This can still lead to plenty of
| scenarios not possible with a compiler.
| aYsY4dDQ2NrcNzA wrote:
| You're right, but in practice the IDE regularly catches
| type mismatches in my code, and it has been hugely
| beneficial.
|
| Then again, I am a fastidious about adding type
| annotations to my codebase.
| anyfoo wrote:
| Fair. My point was that I was able to make python "behave
| more like a statically typed language" to make it
| bearable, but you're right, it ultimately is still a
| dynamically typed language at runtime, with the type
| ultimately bound to the value, and any untyped code still
| getting away from the "compiler" (which is just a type
| checker here), to wreak havoc at runtime.
| sanderjd wrote:
| Agreed. I did this journey twice. It was all static types when
| I was in high school and early college. Then I thought I was
| too smart to need the computer to do all that type checking for
| me ("I know what my program does, I don't need a compiler's
| help!") later in college and early in my career. Then I got
| incredibly sick and tired of working on really big projects in
| dynamic languages lacking the ergonomics of good static
| analysis.
| gkoberger wrote:
| I think it's a grass-is-always-greener thing?
|
| Early in your career, you lean into one or the other. And then
| years later, after you're confident you're right, you find
| yourself trying the opposite paradigm and liking things about
| it.
|
| Both have pros and cons, and if there was a correct answer we'd
| all just go with that one!
| akvadrako wrote:
| I've switched between the two several times - not out of
| choice, just because that's what was needed. The order was
| BASIC, C, Python, Java, Go, Python, with Javascript mixed in
| the for the past few. I mostly prefer dynamic languages
| because static typing is just redundancy. The point of
| programming is to express high-level concepts which can't be
| captured quickly with types - if you don't understand the
| concept of the arguments and return types, you are missing
| the contract. Types can be helpful as the beginning of docs,
| but that's it.
| anyfoo wrote:
| Yes, types are redundant, and that is their entire point.
| Just as much as giving your functions and variables names
| is redundant, you could just number them. So is splitting
| up your project into multiple files, all comments, and even
| structural keywords themselves--you don't need "for" and
| "while", you just need "goto".
|
| Take all that redundancy away and what you get is not even
| assembly, it's exactly machine code. We used to program
| computers that way when they were invented. We still do
| sometimes in extreme situations. We got away from it for
| almost all of programming because it's incredibly error
| prone (and tedious).
| [deleted]
| stingraycharles wrote:
| Yeah, this is something I've been pondering about. I've been
| doing 10 years of C++, and after a 6 months affair with
| Haskell fell in love with LISP. Now I've been doing Clojure
| professionally for about 5 years, and now am in a phase where
| I realize the grass is not green anywhere. I've been shocked
| at some of the bugs in my Clojure code that went unnoticed
| for way too long, and at the same time I remember the amount
| of "compiler fighting" that C++ or Haskell required.
|
| It's just a trade-off, in the end, and depends on what poison
| you can digest.
| m463 wrote:
| Depends on how expressive you are being.
|
| There are some problems where you don't want any barriers to
| getting your idea out of your head.
|
| No rules are best for new exploratory code.
|
| Types and structure are good for existing code.
|
| I wrote Ada years ago when it was newish, and it was hard.
|
| But working on existing Ada code is wonderful.
| realusername wrote:
| The ideal for me would be some strong static typing mode for
| the main code providing all the guarantees you want and some
| dynamic typing mode for the tests which lets you test
| everything well.
|
| The main downside for me of the static typing is that it's
| close to impossible to provide a good testing experience, DSLs,
| mocks and spy objects kind of require some form of dynamic
| typing to be usable.
| yakshaving_jgt wrote:
| That is demonstrably false.
|
| You can absolutely write DSLs, mocks, and spies in a
| statically-typed language.
| YeGoblynQueenne wrote:
| >> Qualities of a good manager share a lot of qualities of a good
| engineer.
|
| OK, you're drunk.
| tomtomtom777 wrote:
| Really? This one aligns pretty well with what I've learned.
|
| It seems that the entire stack of people in software
| development is tasked with identifying problems and subdividing
| them in to smaller problems. This goes for coders structuring
| lines, architects structuring modules as well as managers
| structuring teams of architects and coders.
|
| The quality of a software engineer shines through all these
| layers.
| darkhorse22 wrote:
| This is the humor I needed on a long weekend Sunday morning. Do
| tell us about the industry's dark secrets, 10 years experience
| "senior engineer".
| nadermx wrote:
| This man knows how to write good documentation
| one2three4 wrote:
| That post actually might have started a genre in Reddit. Here's
| the next ones:
|
| https://www.reddit.com/r/ExperiencedDevs/comments/nnw7yd/sob...
|
| https://www.reddit.com/r/ExperiencedDevs/comments/noa841/sup...
|
| I guess there will be more on their way.
| viach wrote:
| This is good he is not drunk enough to tell the main dark truth -
| there are no senior engineers, only some people who finally
| managed how to cope with their imposter syndrome. Oh whait...
| gentleman11 wrote:
| If you keep learning and improving, imposter syndrome never
| goes away. After you settle in, you can get used to what you
| are capable of. I've never lost mine, it's learn one thing,
| discover two more you didn't realize were important that you
| don't (yet) know, recursively
| eqmvii wrote:
| > 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.
| runawaybottle wrote:
| 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.
| vlmutolo wrote:
| 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"
| dijit wrote:
| Antescriptum is probably the closest to the root of the
| word "pro-gram".
| vlmutolo wrote:
| 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.
| rwmj wrote:
| The Stanford law-as-code project used "codex", so I think
| it's good.
| honkdaddy wrote:
| I obviously can't speak to the accuracy of the translation,
| but damn, is Latin a beautiful language. :)
| rottc0dd wrote:
| 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.
| actinium226 wrote:
| 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.
| MikeDelta wrote:
| Indeed, and during rewriting they realize why the original
| code was made that way and how it solves the problem more
| efficiently than their rewrite.
| derekja wrote:
| if they get to that point I'd say it was worth their time!
| dataflow wrote:
| 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.
| palijer wrote:
| 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.
| dataflow wrote:
| 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.
| catlifeonmars wrote:
| Assuming that senior is still working there.
| whateveracct wrote:
| Exactly.
|
| 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?
| boojing wrote:
| It's not only about new hires. You will have to figure out
| things about code that you wrote 3/6/12 months ago.
| whateveracct wrote:
| But you can write code you can understand 12mo from now
| but have that same code be inscrutable to a new hire.
| Definitely different litmus tests.
| andy_ppp wrote:
| 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.
| mgfist wrote:
| > I'd take clear code that wasn't working over code that
| was hard to reason about and somehow worked every day.
|
| Then you'd be out of business.
| BurningFrog wrote:
| This is my extreme counter example:
|
| 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).
| andy_ppp wrote:
| 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.
| [deleted]
| catlifeonmars wrote:
| I look at it this way:
|
| 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.
| andy_ppp wrote:
| You have explained it much more clearly than me! Thanks.
| catlifeonmars wrote:
| 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.
| gravypod wrote:
| 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.
| BobbyJo wrote:
| 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.
| gigatexal wrote:
| I came here to say this. +100 to this.
| jlos wrote:
| As a junior, the best I've seen is surfacing the complexity
| appropriately:
|
| 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
| daenz wrote:
| 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.
|
| Very frustrating.
| runarberg wrote:
| 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.
| catlifeonmars wrote:
| Sounds to me like you have a bored engineer, and their energy
| is misdirected :)
| AlexCoventry wrote:
| > 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?"
| gregmac wrote:
| > "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.
| AlexCoventry wrote:
| Yeah, it's certainly a phase I went through.
| ocdtrekkie wrote:
| 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.
| dehrmann wrote:
| 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.
| mdtusz wrote:
| 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).
| kodah wrote:
| > 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.
| runawaybottle wrote:
| 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.
| daenz wrote:
| 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.
| runawaybottle wrote:
| 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.
| derangedHorse wrote:
| 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.
| JMTQp8lwXL wrote:
| > 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.
| runawaybottle wrote:
| 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).
| josephorjoe wrote:
| i was debugging some very terse, elegant, and dense code. i
| added a bunch of logging throughout to understand what was
| going wrong.
|
| 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.
| eps wrote:
| Should've put it into a branch and added an one-line
| comment to that effect to the master.
| BurningFrog wrote:
| A better approach is usually to write test covering all
| edge cases.
| daenz wrote:
| 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.
| sharken wrote:
| Logging is like a lamp in the dark, you need it.
| josephorjoe wrote:
| 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'.
|
| 3. the UI may be more important than logging
| swader999 wrote:
| Logging at the boundaries or seems is especially helpful.
| fighterpilot wrote:
| Can you elaborate on what you mean by a boundary? You
| mean logging the interface between two services or
| modules?
| mikepurvis wrote:
| 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.
| swader999 wrote:
| Both these above are great answers. It's a bit of an art.
| ratww wrote:
| 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.
| porker wrote:
| 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.
| b3morales wrote:
| 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.
| andai wrote:
| Sounds like the style in which most Wikipedia articles are
| written.
| MikeDelta wrote:
| 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.
| dewclin wrote:
| 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.
|
| "A picture is worth a thousand words.."
| cratermoon wrote:
| "I would have written a shorter letter, but I did not have
| the time." - Blaise Pascal
| cratermoon wrote:
| 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.
| MaxBarraclough wrote:
| 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.
| adriancr wrote:
| > 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...
| sweeneyrod wrote:
| There are various universities that teach Haskell or similar
| languages in first year.
| mplanchard wrote:
| 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.
|
| [0]: http://antirez.com/news/124
| MaxBarraclough wrote:
| > 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.
| craftinator wrote:
| The mantra I use with my team is "comment the details,
| document the strategy".
| MaxBarraclough wrote:
| See the taxonomy of documentation solutions,
| https://documentation.divio.com/ and
| https://youtu.be/t4vKPhjcMZg?t=324
| swader999 wrote:
| I always say that's too hard for older devs like me to
| understand. Go easy on the elder abuse.
| kylestlb wrote:
| Future devs? More like future me... how can I build this so I
| can change it or fix it when PM decides against it in 2 weeks?
| phreack wrote:
| 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.
| austincheney wrote:
| That is frequently misinterpreted to mean use dependencies
| instead of writing code. It's all the same to the product.
| taf2 wrote:
| There is good or bad code - there is only code
| SkyPuncher wrote:
| 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.
| whateveracct wrote:
| 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.
| ritchiea wrote:
| 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.
| whateveracct wrote:
| 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.
| pbourke wrote:
| > 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.
| whateveracct wrote:
| 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!
| tarsinge wrote:
| 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.
| whateveracct wrote:
| That's true, but it's not true in situations where you
| build on more abstract concepts that a newcomer wouldn't be
| able to understand.
|
| e.g. I'll understand my monad transformers in a year, but a
| new hire with no Haskell experience will not.
| BurningFrog wrote:
| 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.
| jeffreygoesto wrote:
| There's even more. In the beginning you are proud if the code
| _works_. Later you find out it's 10x harder to write code
| that _can't fail_...
| hkt wrote:
| Came here to post exactly this quote. I've never seen a wiser
| drunk. So lucid, and so relatable.
| EMM_386 wrote:
| > 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'm paid what I barely consider adequate.
| otabdeveloper4 wrote:
| > programming is webapps
|
| Uhm, sweety, just no.
| Philip-J-Fry wrote:
| 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.
| whymauri wrote:
| >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."
| aszen wrote:
| 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.
| EMM_386 wrote:
| 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).
|
| Just doing my job as usual.
| aszen wrote:
| 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
| EMM_386 wrote:
| > 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.
| yakshaving_jgt wrote:
| 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.
| runawaybottle wrote:
| 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.
| atatatat wrote:
| Peloton easily a tech company compared to Schwinn.
| redisman wrote:
| Isn't their core product some kind of a streaming service
| that you pay for monthly?
| skizm wrote:
| Value created plus how easy they are to replace (supply and
| demand).
| manigandham wrote:
| 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.
| futureproofd wrote:
| 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.
| giantg2 wrote:
| "Sure, $120k + bennies + pension sound great, but you'll be
| selling your soul to work on esoteric proprietary technology."
|
| It sounds great because it is great. I don't make that much and I
| work on boring systems.
|
| I guess those numbers also explain why the author can recommend
| maxing out the 401k. People supporting a family on less than
| $100k don't have $19.5k per year to put into it.
| alexeldeib wrote:
| You have a great point, but let's balance this out with a few
| of the author's other comments.
|
| - OP uses the phrasing senior engineer.
|
| - Never worked for FAANG. This is relevant because $120k +
| bonus/benefits is basically a FAANG new grad. Fairly normal for
| SV tech companies.
|
| - Those numbers likely provide a solid standard of living, but
| as a senior engineer you are likely underpaid.
|
| - Esoteric and proprietary knowledge means if you choose to go
| elsewhere, you will be at a competitive disadvantage compared
| to using industry standard tools. There are of course tradeoffs
| and lots of general learning that comes with experience, but
| all other things equal it's a disadvantage.
|
| > I guess those numbers also explain why the author can
| recommend maxing out the 401k
|
| Yes, but again fairly typical for the target audience I think.
| There are even startups trying to target this market to
| optimize the flow of money from salary -> 401k -> post tax
| contributions/megabackdoor -> other investments, brokerage
| accounts, etc., e.g. https://www.helloplaybook.com/
|
| Just as a sanity check, BLS suggests the median SWE wages work
| out to ~$110k.
|
| https://www.bls.gov/ooh/computer-and-information-technology/...
| giantg2 wrote:
| I'm an intermediate dev, masters degree, 9 years experience,
| non-FAANG, higher cost of living area (not SV, NYC or NVA),
| and work with obscure tech and proprietary tools.
|
| It sucks that I suck. Oh well.
| alexeldeib wrote:
| I really didn't mean for the comment to come across that
| way. I fully agreed with "it sounds great because it is
| great". I just wanted to provide another perspective too.
| gabereiser wrote:
| This rings home for me as well. I remember my (now ex) wife
| saying she was going to quit working and be a stay at home mom
| the day I hit $100k salary. Effectively cutting it in half
| economically. I feel like folks who say these kind of
| recommendations also need to preface the fact that not everyone
| can afford to. I couldn't afford to put _anything_ in a 401k
| for years.
| giantg2 wrote:
| My prior manager said something about everyone should be
| contributing the max. Easy for him to say as a manager...
| with a physician as a wife.
| [deleted]
| gojofika wrote:
| You might check the link to get unlimited Google Voice Number
| https://bit.ly/34tc4BI (100% trusted & quality service
| guaranteed)
| the_arun wrote:
| 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.
| joncp wrote:
| 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.
| dredmorbius wrote:
| 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.
|
| To say nothing of a lot of brain.
| TameAntelope wrote:
| I mistakenly asked to be called the "Staff Engineer" as
| employee #1, I think I'm going to correct to "Principal
| Engineer" as soon as I can.
| 29athrowaway wrote:
| > Work from home is the tits. But lack of whiteboarding sucks.
|
| 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.
| topkai22 wrote:
| Their are authors I generally enjoy that sometimes write
| terrible pieces. They just tend to do it less often.
| fmakunbound wrote:
| > front end AND back end AND... AND... AND... AND... AND...
| AND... Seriously, why are [full stack] webdevs paid so little.
|
| 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"
| blandflakes wrote:
| 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.
| pavel_lishin wrote:
| 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.
| 0xbadcafebee wrote:
| > 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.
| ridethebike wrote:
| >> Third party recruiters are leeches
|
| Can confirm this and it was surprise for me when I discovered it.
| I assumed they would try to maximize $$ in my offer in order to
| maximize their profit. Yet most of them were trying to get offer
| accepted as quick as possible. Seems like more offers with less
| money in each is preferred over less offers with more money in
| each.
| robocat wrote:
| The same dynamic occurs with real estate agents. A successful
| agent optimises for quick sales, while giving the appearance of
| trying to get the best price. Very important to know when
| dealing with agents if either selling or buying a home.
| MeinBlutIstBlau wrote:
| A quick tip for homebuyers/sellers to save on realtor fees.
| Contact the title company and they'll gladly tell you what
| you need to do to close the loan. Maybe not ASAP, but they
| are more vested in you doing the busy work and doing it right
| than they are the worthless realtors. Half the time realtors
| in my state wouldn't even sign the offer to purchase and
| include their info even though it's illegal and they can lose
| their license.
| gentleman11 wrote:
| Recruiters are like men on dating apps: spam as many people as
| possible without reading their profiles, treating people like
| objects
| lordofgibbons wrote:
| Who hurt you??
| josalhor wrote:
| > Tests are important but TDD is a damn cult.
|
| I don't see people commenting on this one! That may be a good
| thing because it means people are not questioning it :)
| l0b0 wrote:
| Techniques aren't culty, people are. I've been practising TDD
| for years, but I've only ever heard of this cult in web forums.
| mrfusion wrote:
| Why does he hate pandas?
| equasar wrote:
| Maybe because they are expensive to breed and keep them alive.
| Not an expert to say if they are worth or not. Nature wants
| them out but human wants to keep them.
| louwrentius wrote:
| > Hacker news and /r/programming is only good to get general
| ideas and keep up-to-date. The comments are almost worthless.
|
| Maybe he is on to something.
| BigJono wrote:
| 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.
| sidlls wrote:
| > I don't know why full stack webdevs are paid so poorly.
|
| In my experience it's because they either don't really know any
| of the stack well enough to do more than implement someone else's
| design, or else they don't know most of the stack well enough to
| do even that without very poor, confusing implementations.
|
| I'll take a backend person and a backend person willing to do
| front end work before a full stack "dev" any day of the week. And
| I'd take the full stack dev before a front end one.
| ng12 wrote:
| > And I'd take the full stack dev before a front end one
|
| So you think one person can't know the entire stack but also
| half of the stack is not complex/important enough to be worth
| specializing in?
| sidlls wrote:
| No, I just would have to think really hard to recall a front
| end specialist who didn't get bogged down in fad chasing or
| wrote code better than a backend dev half-assing it.
| ng12 wrote:
| I would say then that your project is simple enough that an
| underpaid full-stack dev is exactly what you want.
| vsareto wrote:
| >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.
| temp329192 wrote:
| 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.
| mrweasel wrote:
| 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?
| gentleman11 wrote:
| What common position pays better than full stack?
| titanomachy wrote:
| 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.
| dehrmann wrote:
| > If people are trying to assign blame to a bug or outage, it's
| time to move on.
|
| All the best outages have unclear blame.
| OminousWeapons wrote:
| > If people are trying to assign blame to a bug or outage, it's
| time to move on.
|
| This is one of my favorite excerpts. I once worked in a lab where
| we would have frequent catastrophic failures because there was
| never any disaster planning or contingency management plan. I
| personally triaged 3 such incidents alone or with people who
| happened to be there when the problem arose and attempted to
| disseminate some suggestions for how to prevent similar problems
| in the future. No one was interested. People were primarily
| interested in tearing my head off because I hadn't handled the
| problem the way they would have done it (of course, they were out
| drinking beers or sleeping while I was dealing with the issue at
| 12 AM or on a weekend).
|
| After the third time I said fuck it, the next time there is an
| issue I am going to insure my own projects are safe and then I'm
| going home and turning my phone off. Let someone else deal with
| it. That is the not the culture you want to be promoting.
| giantg2 wrote:
| I was on call as a new developer on a system. I was not given
| any procedures or trouble shooting documents. I got a call at 1
| am, missed it, and waited one minute to see if there was a
| message. I did see a voicemail, so I started listening and
| logging on. Before I could even get halfway through, the person
| called again (why not leave the voicemail on the final
| attempt?). So I'm looking for the issue/fix for 5 minutes and
| they tell me they know who the SME is for the functionality, so
| they will call them. Why even call me if you're just going to
| call the SME without giving me time to look at it? I got
| negative feedback from my manager about the way I handled it.
| So, I asked how I should have handled it without any training
| or documentation. They said I should have called the SME. Well,
| I didn't know who the SME was and there's no documentation or
| list of what who is the SME for which part of the system, nor
| was I instructed to immediately call the SME. Again, why not
| just call the SME first if they knew who it was and the SME
| didn't create documentation because they are "too busy".
| tolbish wrote:
| How was the interview process before you got hired on? Any
| warning signs that seem obvious now in retrospect?
| giantg2 wrote:
| The hiring process for the company wasn't special. Of
| course half the stuff they claimed in the interview changed
| later (was hired as a Java dev but was assigned to Filenet,
| they said rhet dont outsource or layoff but have started
| doing both).
|
| This was an internal transfer. There were definitely
| warning signs in that interview. I was desperate because
| they were outsourcing my job in an obscure tech (Filenet)
| and we were expecting a kid.
|
| _The hiring manager said something to the effect of, "I
| was surprised anyone internal even applied to this job"._
|
| 'Warning flag' doesn't do this justice. I have no idea what
| to call it, but desperation required I ignore it.
| tolbish wrote:
| The issues in your earlier post point to a problem with
| the company as a whole. It is surprising that the issue
| is with a specific role.
| giantg2 wrote:
| What do you mean exactly? There are tons of problems with
| the company. Stay long enough at any large company and
| I'm sure there are plenty. The issues can change
| dramatically from department to department.
| tolbish wrote:
| The lack of documentation/procedure, and the process
| issues with others contacting you needlessly instead of
| the SME. They just seem like structural issues that would
| not be specific to one team.
| ameyv wrote:
| > 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.
|
| This got me and somehow bloody true.
| alexander_gold wrote:
| This is an awesome read. Thank you very much for this.
| https://superflyjetskis.shop
| ilrwbwrkhv wrote:
| > When I first started, I was enamored with technology and
| programming and computer science. I'm over it.
|
| This is the saddest. One more soul taken by the shrinking of the
| hacker culture.
| dclowd9901 wrote:
| 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.
| cortesoft wrote:
| 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.
| papito wrote:
| 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.
| the_only_law wrote:
| 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)
| ilrwbwrkhv wrote:
| Try building something of your own just for fun. See if you
| see sparks of your old love back.
| the_only_law wrote:
| 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.
| itake wrote:
| I'm in a similar boat. At my job, the junior engineers do
| most of the coding and I get to enjoy designing systems
| and project management.
|
| I'm considering just hiring people to do the side
| projects I wish I had the energy to write the tedious
| code for.
| JKCalhoun wrote:
| Yes, wait until writing code is no longer your job
| though.
| nowherebeen wrote:
| 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.
| draw_down wrote:
| 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.
| anyfoo wrote:
| 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.
| JKCalhoun wrote:
| 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....
| tgv wrote:
| 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.
| qsort wrote:
| Your second point hits close to home.
|
| 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.
| [deleted]
| freddie_mercury wrote:
| 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.
| redisman wrote:
| 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.
| Mc_Big_G wrote:
| Is it " _the shrinking of the hacker culture_ "? I've become an
| expert in 3 different js frameworks in the last 7 years. Its'
| fucking exhausting.
___________________________________________________________________
(page generated 2021-05-30 23:00 UTC)