[HN Gopher] Senior engineers are living in the future
___________________________________________________________________
Senior engineers are living in the future
Author : pierreprinetti
Score : 262 points
Date : 2022-09-13 14:40 UTC (8 hours ago)
(HTM) web link (www.zerobanana.com)
(TXT) w3m dump (www.zerobanana.com)
| strikelaserclaw wrote:
| a great article, we software engineers are impatient and we tend
| to job hop often. Being an effective engineer is about more than
| knowing how to build systems and code, it also requires deep
| domain knowledge into your company's business and existing
| systems and this knowledge takes years to cultivate at the same
| company. All the superstars at my current company have been here
| for a while.
| dominotw wrote:
| > we software engineers are impatient and we tend to job hop
| often.
|
| This has been the only way to increase our pay beyond measly
| 2-5% growth if you stay at the same company.
|
| I would love to not jobhop and become a 'superstar' but making
| half the pay of your peers is really intolerable.
| gabereiser wrote:
| Especially in the last 5 years. 2-5% bumps for 10-20%
| inflation... gotta love math.
| gabereiser wrote:
| We job hop for a number of reasons. The primary one being
| compensation when their current job isn't keeping up with
| inflation. Another is lack of promotion when you went above and
| beyond (as you were coached to by your manager, for that
| promotion).
|
| Another reason (which is why I do) is that life for some of us
| isn't as stable. I move. I'm forced to sometimes because of
| rent. Sometimes that means having to find a new, cheaper, city
| to live in. Sometimes it's to relocate for that new position.
|
| Next time you see someone who has worked at several companies
| over a decade, ask why and understand their reasoning. I would
| love to work at a company for 20+ years. I can't stay put in
| the same position for that long.
| claytongulick wrote:
| If we're doing honest self-reflection as an industry, another
| reason I see programmers job-hop is because they don't want
| to sleep in the bed they made.
| gabereiser wrote:
| There may be some of that but that hasn't been my
| experience. Most of the time it's because of comp or as
| another poster reminded me, bad manager. If people are
| leaving because they coded themselves into a corner, the
| code review process where you are is broken.
| zmxz wrote:
| While I agree with the reasons you outlined, my experience so
| far shows that number one reason is being the impostor. Most
| people I've had displeasure to work with job hopped because
| they got the job through lies, which showed when faced with
| bearing responsibility and having to finish the project, I've
| seen many just jump the boat.
| gabereiser wrote:
| That hasn't been my case at all. If you have that, maybe
| your interview process is broken.
| silvestrov wrote:
| Another common reason is when you get new manager(s) and they
| don't respect the insight which "All the superstars at my
| current company have been here for a while" have.
|
| Often the superstars are just normal people who really knows
| the business well and therefore what makes sense to implement
| and what should be skipped.
|
| When you earn enough money for a decent lifestyle, then I
| think this becomes the major reason for a lot of people to
| jump ship: you join a company but leave a manager.
| https://getlighthouse.com/blog/people-leave-managers-not-
| com...
| gabereiser wrote:
| I totally forgot about bad managers. Thanks for reminding
| me. I've only left two jobs in my career due to bad
| management.
| abhishekjha wrote:
| >All the superstars at my current company have been here for a
| while.
|
| Exactly. And isn't that memorisation by repetition? If you will
| come across something often you take a good guess on how it
| works.
| macintux wrote:
| Quoting _Groundhog Day_ : "Maybe God _isn 't_ omnipotent.
| Maybe he's just been around so long, he knows everything."
| ChrisMarshallNY wrote:
| _> The first--and most important--thing is to stop comparing
| yourself with others._
|
| I'm "yes and no" on this. The reason is that I often look at the
| work/process/product of others, as inspiration. There's a lot of
| folks that are better than I am, and it is a good idea for me to
| keep an eye on what they do, and how they do it.
|
| What I _don 't_ do, is compete with others. I am not competitive,
| and I'm fine with that.
|
| Unfortunately, that seems to be a bit of an aberration. I am
| _constantly_ having others take a competitive stance with me, and
| it can add a lot of friction; when they refuse to share
| information, make a point of being "snooty" with me, or assume
| that, when I talk about my work, I'm trying to cast their work in
| a negative light.
|
| That's not usually the case. I have very high standards, and I
| hold myself to them. If I will be incorporating the work of
| others, in mine, then I'll hold them to high standards.
|
| Otherwise, I've actually found a lot of gems in things like
| sloppy StackOverflow examples. Their lashup code may solve my
| problem, and I can take their solution, and refactor it into one
| that meets my own bar. I don't waste any time, thinking
| negatively about the other person. In fact, I'm usually fairly
| effusive, in my thanks. The person is often coming from an
| academic point of view, and are not concerned about the
| practicalities of shipping software.
|
| There's so damn much negativity, these days; often driven
| directly by competitiveness, that I feel I need to reduce my
| contribution to it.
| w10-1 wrote:
| The article's perspective is that the superiority of senior
| engineers lies mainly in the access they have to other people.
| I.e., they're not better, and it's not because of their
| experience; it's because of their position.
|
| I.e., the politics of resentment have reached even here. Do
| junior engineers prioritize avoiding embarrassment over learning?
|
| This is a really, really tough nut to crack. And let's not always
| hand-wave about safe cultures.
|
| When in senior roles, I try to model learning from failure and
| sharing everything, from short script tips and fantastic books to
| leads and gossip. Also sit together.
|
| But still: juniors have literally complained that it doesn't
| matter when I fail, because I'm already "made". Their sense that
| they have to prove themselves, and advance on some ladder, hangs
| over them always. Even, or especially, at leading companies,
| where _everyone_ there is good.
|
| Part of it may be style: if after a while you drop all the
| "please" and "maybe", you risk people confusing assertiveness
| with authority (triggers).
|
| Feed them achievable projects where they can hide failures and
| show success. And give them their say. Doing this adds a new
| dimension of complexity to meetings and work factoring, but they
| eventually chill.
|
| If it's better to teach someone to fish, think of it as producing
| fishermen instead of fish.
| bluGill wrote:
| > But still: juniors have literally complained that it doesn't
| matter when I fail, because I'm already "made". Their sense
| that they have to prove themselves, and advance on some ladder,
| hangs over them always.
|
| They are not wrong. I've been around long enough to earn some
| trust. I can (and have) made some major mistakes that would be
| reflected on a junior's raise, but I get by with it. I'm also
| working in places where those mistakes are more likely because
| we don't trust juniors in them. I like to think I make less
| mistakes than the juniors would, but I'm not sure...
|
| If you are a junior, just wait - your turn will come.
| Invictus0 wrote:
| HN headline tomorrow: Senior engineers are literally gods
| decebalus1 wrote:
| Wait until you hear about Staff engineers.
| Spooky23 wrote:
| Senior engineers are worms. Bow before the principal engineer.
| jasonlotito wrote:
| Except that's not at all what the article is suggesting. Quite
| the opposite.
| Invictus0 wrote:
| > it is _literally effortless_ to accidentally cultivate the
| impression of being some kind of wizard
| olddustytrail wrote:
| A quote which shows you were wrong and the person you were
| responding to was right. You do know what is meant by
| "impression" in that sentence?
| atomicnumber3 wrote:
| My impression of that bit was that the author was saying it
| may look like a senior engineer is a wizard, but actually
| it's just experience and it's not magic.
| wiseowise wrote:
| > just
| zb wrote:
| Exactly, but also that it's quite often experience you
| had _this morning_ , not e.g. over the last 5 years, that
| makes the difference.
| smrtinsert wrote:
| Relevant KRAZAM:
| https://www.youtube.com/watch?v=eSqexFg74F8&ab_channel=KRAZA...
| skrtskrt wrote:
| Often as I've grown in engineering I've wished there was just a
| series of books that I could study backwards and forwards in
| order to just _become_ a highly knowledgeable engineer.
|
| Instead it turns out that I'm just piling little pebbles of
| knowledge and experience on top of other ones, and I couldn't
| look back and design a book or a course or a curriculum to bring
| my old self to where I currently am. There are some pebbles just
| sitting on the side that haven't had an opportunity to be
| integrated into the pile yet, and some never will. It's all so...
| random
| manv1 wrote:
| Senior engineer = experience. For example, when building an HA
| system with embedded devices the devices shouldn't use the DNS
| cache and should ignore the TTL. They also shouldn't validate
| expiration dates on TLS certificates.
|
| Why not? Because stuff will fuck up if you don't do that.
|
| Also, you have to deal with the "regional power failure"
| situation, where every one of your devices will call home at the
| same time. Do devices need provisioning before they work? Because
| if they do, you need to handle that load fast.
|
| Do you believe a MAC address is unique and universal? It isn't as
| unique as you think, and not everything on the internet has a MAC
| address.
|
| Essentially, someone who's been around for a while realizes
| there's a difference between the spec (correctness) and what
| needs to happen to get shit to keep working (customers).
| [deleted]
| onion2k wrote:
| This explains why I'm so tired.
| zackmorris wrote:
| I was thinking the same thing, that as we gain experience, it
| can sometimes get harder to not see problems, which can lead to
| environmental depression.
|
| The flip side is that I used to suffer from agism-related
| depression, because I generally knew the answers but was
| powerless to sway anyone because they thought that I was too
| young to know what I was talking about. That didn't end until I
| hit middle age and realized that the problem wasn't so much
| about my performance, but my inability to communicate and set
| boundaries like older people do.
| [deleted]
| revskill wrote:
| Senior means two things:
|
| - Have experience
|
| - Self learning though above experience.
|
| I met many experienced developers, but most of them failed at
| step 2. To me, they're still junior.
| layer8 wrote:
| I would reformulate #2 as learning to figure out things on your
| own, i.e. not to bail out as soon as something is outside of
| what you're familiar with. The ability to go one level deeper
| to find out how things work under the hood. The ability and
| interest to extend your horizon, to pick out the learning
| material you need for familiarizing yourself with something
| new, without needing it to be served on a plate by someone
| else.
| bluGill wrote:
| That is only half of #2. The other half is knowing when to
| bail early.
|
| More than once I've proven my value as a senior engineer by
| refusing to do work that should be left to someone else. Sure
| I could figure it, but it would be a waste of time when
| someone else can. Sometimes because it is obviously an easy
| task, and thus good for a junior engineer to learn to figure
| things out on. Sometimes because it is something I'll never
| need again and I know we can hire a contractor who already
| knows how to do it.
| layer8 wrote:
| I would put "knowing when to bail early" on the
| "experience" side, so #1.
| roflyear wrote:
| Can you give an example of a failure at step 2?
| revskill wrote:
| A 10 years Java/PHP developer doesn't know how to use Golang
| on the job in 3 days.
| onion2k wrote:
| In other words you're inventing some silly criteria that
| I'd guess you'd pass that others wouldn't. What I would say
| to that is that if you dismiss someone else's experience
| because they can't do some task you think they should be
| able to do rather than understanding that their experience
| probably brings _something else_ to the team then that 's
| your failing, not theirs.
|
| For a little annecdata - I've been a dev for 25 years, with
| a senior level (and above) title for about 80% of that, and
| I reckon I'd take at least a couple of months to get to a
| point where I was happy with golang. I guess that makes me
| a junior in your opinion. However, instead of being able to
| get up to speed with a language quickly I bring a fantastic
| level of respect for users, a talent for technical writing,
| a belief that documentation is actually important, a sense
| of fun and joy in making high quality software, and a deep
| understanding of browser-based software. If I was looking
| for a new team member I'd seek out someone a bit like
| myself rather than someone who can learn a new language
| faster.
| claytongulick wrote:
| Also importantly, it sounds like you would bring the
| understanding that surface level productivity is not the
| same thing as mastery.
| rco8786 wrote:
| > a talent for technical writing, a belief that
| documentation is actually important
|
| This is, IMO, a hallmark of "senior" engineers and above.
| Much more important than language adoption/choice.
| agumonkey wrote:
| For a bugfix or a whole new module ?
| 3pt14159 wrote:
| Eh--I don't know. Code a test or two and something basic
| with just the lang? Sure.
|
| The whole stack? Takes about a month to get productive and
| about three months to really internalize. Think interned
| strings in Python vs symbol exhaustion in Ruby. Or
| serializers in Django Rest Framework working as both input
| validators and output generators compared to stock Rails
| views.
|
| Super similar languages with lots of similar frameworks and
| libraries, but they have these edge cases that still crop
| up.
| lupire wrote:
| You've spawned a silly thread, because mastering a language
| is a spectrum that takes years.
|
| In 3 days someone should be able to fix a small business
| logic bug in a program in a new language, like copy-pasting
| a if-block to handle a new simple case, or improving an
| error message by grabbing a variable from context and for
| setting it for output, but not write a useful program.
| metadaemon wrote:
| A better example might be not learning from past mistakes,
| or asking the same question multiple times, even if framed
| in a different context.
| rr888 wrote:
| "Use" is pretty vague. Can run the process and make a small
| fix should be easy. Writing idiomatic code in a new
| language takes months.
| abhishekjha wrote:
| Well, golang is a tough language.
|
| I am stuggling with helm/kubernetes and the new company's
| ecosystem where everybody is new in the team. We are
| expected to deliver according to a plan while we keep
| hunting for relevant info.
|
| I would say the second point is a lot more nuanced than
| stated.
| treeman79 wrote:
| Saw a company fail because all developers were expected
| to master k8/helm etc. A couple of us got the hang of it
| well enough to get by. But almost everyone failed too.
|
| Even those of that had it working, it was a huge time
| sink.
| skohan wrote:
| That's why I'm a huge fan of server-less. Let Amazon or
| Google handle the tough parts until your company is big
| enough to have to optimize for server costs.
| funklute wrote:
| In what way were the developers expected to "master"
| k8/helm? In the sense of actually making contributions to
| the k8/helm setup, or simply using an existing k8/helm
| setup to provide a development environment? Was there any
| "expert" person on the team that everyone could ask about
| k8, or was everyone simply supposed to pick things up on
| their own?
|
| (asking because my own team is currently moving in this
| direction, and I'm curious about the pedagogical
| challenges we might face)
| robertlagrant wrote:
| Anyone who is either insecure about their own skills, or
| so proud of their skills in their area that they can't
| face being a beginner in another area, will struggle and
| come up with reasons not to learn it. And they'll tell
| their nontechnical colleagues or managers that the idea
| is overengineered, or they'd add more value elsewhere,
| until it happens or they leave.
| kuramitropolis wrote:
| Ima be facetious here and suggest that the above is meant
| in the sense that K8 is the ultimate leaky abstraction
| and you have to "master" it first before even starting
| starting to achieve anything with it.
|
| And Helm is just closing the cycle of Samsara - if you
| really want to base your operations on string templating,
| just use bash lol. Or hand-written forms on paper, still
| faster and you still get a better idea of what's going
| on.
|
| There's also the problem of many developers nowadays just
| not having the hacker mindset/actual high-level abstract
| thinking/attention span, so instead of seeing the whole
| of K8S as the pointless kludge it is, they only see the
| interface - yay, YAML, I know that language! (usually
| they know it from everyone's favourite "dead" tool,
| docker-compose; which is a gem) - and they go on to fight
| with it tooth and nail, with corresponding feelings of
| "achievement" and "mastery".
|
| I think the "10 years PHP/Java -> 3 days Go" thing from
| granduncle's cousin post is meant to point out this
| particular paradoxical situations.
|
| But it could hurt people's feels to say it like that so
| let's just let Google do all our thinking for us instead.
| We truly live in a gilded age of computing.
| 0x457 wrote:
| > Well, golang is a tough language.
|
| golang is a language designed for fresh graduates to
| write fast code without much thinking. It isn't tough at
| all. For engineers that never worked with CSP paradigm,
| or rather for engineers who only ever work with Java
| style OOP and concurrency, it might be weird to adjust,
| and they will spend 3/4 of their time bitching about how
| much it is easier in language X.
| Sholmesy wrote:
| > Well, golang is a tough language.
|
| This _could_ be true for some, but it directly conflicts
| with the stated goals of the language. Most people (that
| I've spoken to) would consider Go to be a simpler
| language, with fewer features, than other comparable
| languages.
| ASalazarMX wrote:
| Python is also an easy to learn language, and you'll
| likely make correct programs quickly. Idiomatic Python,
| though, is a longer road. You won't feel confident to
| open source your code for months.
| Gwypaas wrote:
| The issue with Go is the implicit footguns you will
| inevitably hit. Starting out with Go sure feels like a
| super power because of the simplicity and productivity,
| until the code base has grown and you now meticulously
| inspect every single line to understand the entire
| context a change is bringing, because you do not trust it
| in isolation to be correct.
|
| https://eng.uber.com/data-race-patterns-in-go/
| lupire wrote:
| You use Golang as a replacement for many Baah and Python
| programs, and never touch concurrency.
|
| Concurrency is tricky, and that is true in every
| language, but less so in Go.
| everforward wrote:
| > I am stuggling with helm/kubernetes and the new
| company's ecosystem where everybody is new in the team.
|
| I can't speak for Helm, but working with Kubernetes in Go
| is almost uniquely difficult. Kubernetes modules are
| designed to be dynamic, and Go's type system doesn't make
| that easy, which leads to some cludge-y code out of
| necessity.
|
| Plus the API is vast, and it's sometimes not clear what
| package you need for a particular use.
| macintux wrote:
| Not everyone learns at the same pace, not everyone is great
| at bootstrapping.
| kilbuz wrote:
| Why is 3 days, likely with competing priorities, a
| reasonable timeframe to learn a new language well enough to
| contribute production code in your estimation?
| revskill wrote:
| Just a JIRA task for next sprint with 2 points assigned !
| skohan wrote:
| I've had to jump into projects with unfamiliar setups and
| even unfamiliar languages more than a few times, and
| after a certain point it's all just problem solving. Like
| I had to fix critical bugs in an orphan rails project
| with next to no experience with Ruby and it worked
| somehow.
|
| Are you going to write elegant, idiomatic code in the
| first week? Of course not. But give the task "make the
| system do X", 90% of coding is knowing how computers
| work, and the other 10% is knowing how to search on stack
| overflow to be able to translate what you want to do into
| the desired syntax.
| tikhonj wrote:
| The trick is that Go isn't a new language, it's an old
| language with a new coat of paint.
| nostrademons wrote:
| 3 days to learn how to write syntactically-valid Go or 3
| days to learn how to write idiomatic Go?
|
| Idiomatic Go has some very large differences from
| idiomatic Java or PHP, including things like 1) the
| reliance on multiple return values and early exits for
| error handling 2) interfaces instead of inheritance 3)
| plain old data structures instead of everything-is-an-
| object 4) goroutines 5) table-driven testing 6) complete
| reliance on gofmt for formatting rather than doing it
| manually. And that's just the stuff that I'm aware of, as
| someone whose primary language is not Go but worked in it
| for about 3 months.
|
| My definition of a senior dev would be someone who's
| aware that they can't just pick up a language in 3 days
| and write idiomatic good-quality code, but expects that
| they're going to have to keep learning for multiple years
| to really master a language. It's the metacognition of
| realizing how little you know and always continuing to
| learn.
| fisf wrote:
| A person proficient in multiple programming languages
| absolutely knows all of the 6 concepts - it's just cases
| of 'aha, go allows me to do x,y,z and this is how things
| should be done'.
|
| I basically learned ideomatic go in a week, by skimming
| over the "effective go" guide and cross referencing
| concepts to other languages I know -- there is really
| nothing inherently 'new' in Go that would require years.
| It's a deliberately simple language.
| skohan wrote:
| "code quality" is not real, it's just something software
| engineers like to argue about like sports.
|
| We like to talk about how code is written, because we
| look at code all day. The rest of the world only cares
| about what your code does once it's compiled.
|
| Senior engineers solve problems. They're not overly
| concerned with ticking all the boxes just so they can get
| a "good code" sticker.
| ianbutler wrote:
| Code quality is very real, but the bounds you have to
| exceed before lack of quality start to bog down
| development are pretty large.
|
| As a senior I can pretty quickly tell in the languages I
| write in often, when something is a smell, and if you
| keep repeating some code smells for a like a year you'll
| start seeing compounding effects on development speed.
| Understanding when to allow those with good reason and
| when to coach someone to stop doing those is an important
| skill for a senior imo.
|
| But it's definitely not immediate, way more of a
| pernicious concern, the codebase will effectively rot
| until it's painful to make changes.
| nostrademons wrote:
| Eh, I've seen a number of startups sunk (as in went-out-
| of-business sunk) because of code quality issues.
| Eventually you hit a wall where every bug you fix
| introduces more bugs, and the product does not converge
| to a state where you can launch it. Then the VCs start
| getting impatient and you run out of money.
|
| The point where this happens depends a lot on problem
| domain. If you're doing well-understood CRUD-screen
| database stuff but applying it to a novel business
| domain, you're probably not going to hit code quality
| issues. If you're doing heavy algorithmic, OS, financial,
| or networking stuff, though, where failures compound and
| any one bug might take the whole system down, you really
| want to pay up for experienced developers that have seen
| all the ways these systems can fail.
| ianbutler wrote:
| Oh sure, I didn't mean to suggest code quality can't kill
| a business. I however think like you said it's very
| domain dependent on how quickly that happens. I think
| taking on no debt wrt to code quality is impossible
| though and knowing how to take on that debt and pay it
| down to effectively meet the broader business goals
| without doing irreparable harm is something everyone has
| to contend with while being a dev.
|
| That said, I can really only speak to web api dev, data
| engineering and search. I'd say out of all of those
| search was the tightest area with regards to quality and
| even then I was lucky to be working with another very
| talented dev. Him and I didn't run into very many issues
| we were unable to solve with scaling the technology even
| after hitting 100m pages or so and we could have kept
| going on scale but we were cost constrained, navigating
| the business side was far more challenging for us.
|
| I'll admit as well I've been pretty lucky so far to work
| in situations where code quality is considered and
| managed and haven't yet worked somewhere where the
| concerns were entirely ignored or the team didn't care.
| breischl wrote:
| >The rest of the world only cares about what your code
| does once it's compiled.
|
| People in your company (including non-engineers)
| definitely care, because code quality bears on how easy
| it is to debug problems and how easy it is to implement
| new features or fixes (or sometimes if a feature is even
| practicable).
| nocman wrote:
| > "code quality" is not real, it's just something
| software engineers like to argue about like sports.
|
| While I do agree that many developers sometimes like to
| argue about "code quality" _too_ much (and I 've probably
| been guilty of that at times), "code quality" is
| _definitely_ a real thing. I have have interacted with
| code bases that were a joy to read /modify, and I've
| interacted with code bases that made you pull your hair
| out at every turn (and also many levels in-between the
| extremes). It is not always a case of just "arguing for
| the sake of arguing".
| skohan wrote:
| Probably I am being a bit hyperbolic. I could be more
| precise and say: code quality is a solution you should
| reach for if and only if you are running into real
| maintainability problems.
|
| But I strongly disagree with the sentiment that someone
| should not write code in a certain language, or should
| not contribute to a project until they know how to write
| idiomatically according to all the "accepted" best
| practices. It's a pedantic and elitist attitude which has
| little to do with making good software, and runs counter
| to the practice of learning how to use a language, which
| is necessarily a process involving ignorance, trial and
| error.
| lupire wrote:
| By the time you have real maintainability problems, it's
| too late to improve code quality.
| skohan wrote:
| It's never too late. I've had to pick up development on
| orphan projects before, and some of them are real
| stinkers. You can always quarantine the bad bits and
| start to impose a proper separation of concerns.
| nocman wrote:
| I think somewhere in the middle is a good place to start.
| This can be managed by limiting the scope of code a
| "language newbie" writes (until they get reasonably up-
| to-speed) -- if/when that is possible. It also helps if
| you have someone experienced in the language who can help
| point them in the right direction when they need help.
| That can be a challenging thing to do well. Deciding
| where to provide direction, and where to just let them
| figure stuff out on their own can be difficult. You can
| come off as being too picky, or just being a jerk when
| you were just sincerely trying to help. I think to do it
| well you have to be vigilant about keeping your own ego
| in check. It has been my experience that most people who
| are fairly good at something (present company included)
| can slip into the state of "thinking more highly of
| themselves than they should". That's always counter-
| productive, and in my experience good "mentors" (or
| whatever you want to call them) are the one's who excel
| at avoiding it.
| yazaddaruvala wrote:
| Really all it is is "3 days to showcase you have a
| working compiler, ide, formatter, can run the tests, and
| are familiar with the CR tools".
|
| The rest of it is learned (hopefully quickly) through the
| CRs, and any senior engineer should be comfortable making
| a few idiomatic mistakes in their CRs that they learn
| from.
| lupire wrote:
| None of that is "3days" . That's all the negative days
| before you start using the language.
|
| I could do all those setup things in N days without ever
| learning any programming language.
| yazaddaruvala wrote:
| I think you've misread / misunderstood the original post.
|
| "3 days into the job"
| 8note wrote:
| That sounds like a description of the team onboarding
| process, not the engineer doing the onboarding.
|
| Any engineer should be able to do this because the team
| has written good wikis and has working build tools,
| tests, etc
| [deleted]
| Existenceblinks wrote:
| I'd give them 1 week. And measure again at starting of week
| 3, if they are still struggle, that's very likely they suck
| at learning.
| ASalazarMX wrote:
| - Are you still struggle?!
|
| - Y-yes...
|
| - You are fire!
|
| Note: Sorry for the cheap joke, I also make frequent
| grammatical errors in English.
| Existenceblinks wrote:
| Usually, they will appoint a cold room for 1-1 meeting to
| hear what's going on. And find out whether it's hiring
| process or teaching process that's the problem.
| lupire wrote:
| if they are still struggling _on the same thing_
| treeman79 wrote:
| Had a guy with 20 years experience at a top mail carrier
| come in for a senior position. We were very excited to
| interview him.
|
| He had spent the 20 years copying the same html file and
| changing the text for whatever was needed.
|
| Struggled heavily with the concept of a loop.
| lupire wrote:
| > copying the same html file and changing the text for
| whatever was neede
|
| Can also describe a complex single-page web application
| :-)
| giantg2 wrote:
| "He had spent the 20 years copying the same html file and
| changing the text for whatever was needed."
|
| Dream job right there.
| trey-jones wrote:
| I would never fault someone for not being able to pick up a
| language and use it competently in 3 days. I understand why
| you use this as an example, with having samey syntax, but
| there is still nuance. I think the bigger indicator is
| you've been in the industry for 10 years and call yourself
| a PHP/Java dev. At this point you should have dabbled in
| probably 10-100 ways of solving problems depending on what
| your 9-5 looks like.
| ASalazarMX wrote:
| Same. I've never seen anyone become proficient in a new
| language/platform in less than a year. Sure, you could
| learn Go's syntax, use it in the style of Java/PHP, and
| make it work, but that is not being proficient in Go and
| its idioms.
| Jtsummers wrote:
| A year? That's a very long time for anyone who isn't a
| novice to learn a new language.
| AlotOfReading wrote:
| I would bet hard money that even an experienced developer
| wouldn't learn C in a year (e.g. avoid or recognize most
| UB and security issues) without prior exposure. I'll
| grant that C is pathological in that respect though.
| Jtsummers wrote:
| Maybe we have different bars for what it means to learn
| something, but if I worked with an experienced dev who
| took a year to learn C (and there was an actual need for
| them to learn it) I'd question their claimed experience.
| It shouldn't take more than a few weeks to be capable of
| using C if you have a decent background with other
| procedural languages and already know the difference
| between heap and stack storage (so you don't make the
| mistake of a past colleague of trying to return data on
| the stack, he didn't claim to be experienced though).
|
| Learning a language and mastery are separate things. An
| actual experienced dev should be able to hit "competent"
| in any new language within weeks so long as it's within
| the same family of languages they've used in the past.
| Procedural languages, like C, are pretty much squarely in
| the middle of what everyone has learned unless by some
| fluke they started and continued with Haskell and similar
| languages and never touched any of: Go, Rust, C#, Java,
| Javascript, Lua, Python, Perl, Ada, Pascal, Fortran,
| Matlab, BASIC (various forms), and a hundred other
| languages.
| Adiqq wrote:
| There's a lot of baggage that comes with each language. I
| could probably learn any language at that point, but it
| also takes time to learn whole ecosystem, mostly used
| libraries and tools. You typically can't do this in week
| or two, because you need to actually write something and
| see how it feels, if there are any surprises.
|
| You would probably not want someone with little
| experience in given language, to touch production
| codebase without review, because there are always traps
| that you might've not encountered in other languages.
|
| I typically don't touch low-level programming languages,
| but once I had to use C to write some small adapter to
| communicate with some Oracle product. I did it, it worked
| as expected, but I would not be able to use it
| efficiently for complex solutions without more experience
| with creating and managing solutions in C.
|
| I can also write in Go with some basic proficiency, I
| felt confident at one point in my abilities, but when my
| code got reviewed by someone specialized in Go, he would
| propose several improvements that did not cross my mind,
| because I had less experience in Go.
| Jtsummers wrote:
| > You would probably not want someone with little
| experience in given language, to touch production
| codebase without review, because there are always traps
| that you might've not encountered in other languages.
|
| I never said otherwise. This is part of the distinction
| between competence and mastery. I would not expect most
| people to master a new language in just weeks, but a
| senior developer should be able to be competent within
| weeks. Now, would they have a _product_ or substantive
| (non-trivial) change to show after those weeks? Maybe
| not, that might take a few more weeks, or longer if it 's
| larger in scope.
|
| > I can also write in Go with some basic proficiency, I
| felt confident at one point in my abilities, but when my
| code got reviewed by someone specialized in Go, he would
| propose several improvements that did not cross my mind,
| because I had less experience in Go.
|
| That's part of learning, but it probably didn't take you
| a year to learn enough Go to get something in a
| reviewable (if not passing review) state.
| idontpost wrote:
| > You would probably not want someone with little
| experience in given language, to touch production
| codebase without review
|
| I wouldn't want anyone, in any language, with any level
| experience to touch production codebase without review.
|
| Not even K&R themselves.
|
| So that's a ridiculous straw man.
| Adiqq wrote:
| Yet it happens in many companies, when team is working on
| non-critical systems or in extreme cases, even on
| critical systems. I sometimes feel like some people in IT
| are detached from reality, not everything is mission
| critical system and not everything has high quality,
| because there's a lot of people in IT with all kind of
| background and there all kind of clients with different
| sets of requirements. It's business, not utopia.
| ASalazarMX wrote:
| > Not even K&R themselves.
|
| This feels like a town cop enforcing strict speed limits
| in the couple of miles that fall in their jurisdiction.
| If K&R show up at your door and want to touch your
| production code, you just let them, bring them coffees,
| and ask for autographs. Even if it breaks, it would be an
| amazing story.
| AlotOfReading wrote:
| They might be able to get the compiler to accept their
| code, but that's not a good bar for competence in C. I
| personally wouldn't consider someone competent in it
| unless they're deeply familiar with UB and other language
| warts because it's too dangerous to do otherwise. UB can
| have nonlocal effects and "time travel" so any UB
| anywhere in the program legally invalidates the entire
| program, regardless of whether it would otherwise work.
| Most other languages have (wisely) decided not to carry
| that legacy forward.
|
| As we all know, the subject of UB and the practical
| ramifications of particular instances is a topic few
| people could reasonably learn in weeks or even months.
| ASalazarMX wrote:
| A year is enough time so your new language stops teaching
| you new things every week. I agree that superficial
| knowledge can be attained quickly, but learning the
| idioms, tooling, libraries, gotchas, performance
| bottlenecks, warts, etc. takes months.
|
| Maybe six months if you're very good, but I'd wait a year
| before assigning a big project to someone new in a
| language/framework. Still wouldn't consider them a master
| with just one year of experience, mastery of a modern
| language can take years, you can always go deeper.
| 0x457 wrote:
| Being proficient and using it are two different things. A
| year to learn? What are you talking about, in a year you
| can get someone who never used a computer beyond a
| browser to learn just about any commonly used programming
| language. Yes, they won't be level 99999 one-man-army
| ninja fullstack senior engineer, but they would be able
| to write code.
|
| If you had 10 years of java, you can absolutely learn how
| to write Go in 3 days, unless your 10 years of java is
| "writing CRUD in Java 6 with libraries available in
| 2006".
| roflyear wrote:
| I dunno. I haven't had much need to do a major project in
| another language other than Python for the last 10 years.
| Is that an issue?
| trey-jones wrote:
| I recognize the value of expertise in a language. I
| recognize that I have touched so many different languages
| that any "expertise" that I might have possessed at some
| point has probably passed as I've missed out on new
| features, etc. I guess I would just expect you to be
| _really_ knowledgeable and efficient in python!
|
| So I don't think it's an issue, if that's been your job.
| My job exposes me to a lot of different technologies:
| many programming languages and endless different software
| that might be supporting a web application (databases,
| webservers, firewalls, etc.). I consider my value to be
| looking at problem and being able to spot 10 different
| possible points of failure in a system in my mind and
| order them by priority based on likelihood and ease of
| troubleshooting. And this is something that I think is
| only gained through experience and that's what separates
| me from someone who just started.
| peteradio wrote:
| Who said you need competence, looks like that was your
| own insertion, haha. But seriously is it not unreasonable
| to be able to write some non-deep dive code in a new but
| similar language in just a few days? 3 days is a long
| time to read and ask questions.
| trey-jones wrote:
| What purpose does it serve though? I think being able to
| read and understand a Go program is a better example.
| That does seem like a reasonable and useful ask in 3 days
| for a veteran PHP/Java dev, and something that is more
| likely to come up in practice. What is the context of the
| former? "Welcome to our team. I know we didn't hire you
| as a Go dev. You have 3 days to "be able to write Go".
|
| I have long subscribed to "A programmer is not language
| specific", and I don't hire based on the languages you
| know. But that first task is "Here is access to the repo.
| _Read_ and understand what our code does today please. I
| 'll answer questions within reason." Acquiring the new
| language happens as a side effect.
| pantojax45 wrote:
| If you hire someone in a language they don't know, you
| expect them to learn on the job. It's reasonable by day 3
| to expect them to show some code - even if terrible.
| macintux wrote:
| At some companies you're still in onboarding hell on day
| 3.
| roflyear wrote:
| I would say, most? Or maybe I have been really unlucky,
| lol! I don't think it is POSSIBLE for an employee at my
| current company to be productive before week 2.
| adamsmith143 wrote:
| I learned it in 2 hours so you are pathetically junior
| compared to me.
| neon_electro wrote:
| The real 10x engineer right here!
| ASalazarMX wrote:
| I suspect he learned it in the future.
| Existenceblinks wrote:
| I can figure out its internal AST once I stare at the
| lang's codes. \s
| Existenceblinks wrote:
| My friends who won't step 2 mostly because they are limited by
| their circle's culture. There is this large enterprise corp
| network that can keep you stable forever, these guys never see
| outside world so global maxima is not a thing.
| ironmagma wrote:
| I think you can be senior without experience. To me, senior
| means "can handle ambiguous/incorrect/incomplete problem
| definitions."
| [deleted]
| BoorishBears wrote:
| I learned how to program starting on calculators in middle
| school and eventually moving up to games.
|
| Looking back, I accidentally turned my first full time into a
| senior position almost immediately
|
| A local company gave this self-taught developer a chance as a
| glorified intern, but a few weeks in and I reimplemented a
| project they had given to a contractor in a weekend after
| overhearing their back and forth.
|
| We ended up shipping my MDM on hardware across the country
| that Christmas, less than 3 weeks after that weekend project,
| and I spent the next 2 years extending it as a platform:
| completely driving the functionality that sales would then go
| and sell new clients on, designing and implementing an
| autoscaling analytics backend and frontend, embedded V8 so
| that client's engineers could script the product without
| mucking in my codebase about with source access ;)
|
| I remember I got a 25k pay raise at one point by simply
| saying "I was thinking I'd make more once we got past the
| evaluation period"
|
| I had actually been trying to ask for us to set up a
| performance review, but in retrospect they were probably
| terrified of losing this guy they were paying half a senior
| dev's salary to do 2x the work, and were ok paying 2 thirds
| of a senior dev's salary instead...
|
| In some ways I feel like the work I did there was more senior
| than the work I do now, at least in a technical sense. I
| think it's the soft skills that come from experience
| omreaderhn wrote:
| This skill comes from experience. If you're talking about
| experience in a particular subdomain, then yes for sure.
| ironmagma wrote:
| The trick is, what people refer to "experience" in the
| workplace is very strictly defined as workplace experience
| in your role. But you can get experience from a wide
| variety of tasks, even ones that don't involve your current
| career. Working with vendors to organize a convention can
| prepare you for writing software. Or a volunteer/school
| software project could prepare you for a paid role, but
| nevertheless it is not counted.
| jahewson wrote:
| No, you have you know the traps and specifically you have to
| know your own biases and this only comes with failure, thus
| experience.
|
| Show me a mid-level engineer and I will show you someone busy
| walking straight into a trap.
| ironmagma wrote:
| When commercial hiring managers say "experience" though,
| they don't count school projects, volunteer (OSS) projects,
| or career-adjacent projects. That is the source of
| dissonance. You are right, it's just that you* vs. the
| managers have different definitions of the word.
|
| * also me sometimes, but that's confusing since I just used
| the commercial definition of the word a few comments above.
| PLenz wrote:
| The difference between 10 years of experience and 1 year of
| experience 10 times
| lifeisstillgood wrote:
| Oh God. No.
|
| "Ensure that you are fulfilling the expectations of your manager"
|
| Please please do not assume your manager is any good at their
| job. Talk to your users. Find a way to identify them and get
| feedback from them. Keep your manager in the loop sure. But don't
| wait for requirements to come down from on high.
|
| "Every step up in job title is equivalent to living perhaps 1-2
| days further into the future." No. If an organisation passes
| information down through the hierarchy then by the time it
| reaches you (it's more like 1-2 weeks if not months into the
| future) then it's already moved on.
|
| The US military tries hard to put decision making at the front
| line where it is most up to date. At the Battle of Jutland the
| British ships in the fleet had to radio its positions and
| sightings back to London, so London could update its "board" and
| radio to the Admiral in the fleet. This Admiral was this working
| on data that ships a mile or two away from him had had hours ago,
| but he was only just getting. This lead to an inconclusive
| battle.
|
| Anyway.
|
| Open information is way important.
| ClumsyPilot wrote:
| > The US military tries hard to put decision making at the
| front line where it is most up to date.
|
| Business leaders love to imitate the military, but isnt it
| ironic they are emulating the institution that has the most
| government involvement and central planning?
| devonkim wrote:
| In terms of how it's supposed to be structured the military
| is heavily centralized but that model has broken down
| considerably as the US has had to face far more dynamic
| adversaries than before. It's a popular perception but most
| groups in the military branches operate a lot closer to
| Silicon Valley in many respects than people give them credit
| for.
| dilyevsky wrote:
| On the surface level it should make sense bc in war stakes
| are high so you'd think "survival of the fittest" would
| apply. In reality I'd say it's far from being the case but it
| makes suits feel more important so here we go again
| bluGill wrote:
| > Talk to your users. Find a way to identify them and get
| feedback from them. Keep your manager in the loop sure. But
| don't wait for requirements to come down from on high.
|
| As a senior engineer that is what my manager expects me to do.
| In fact I'm often expected to define the requirements before
| working on them. Often when I get the requirements refined
| enough I hand them off to other engineers.
|
| Of course there is personality involved here. I pass things off
| before I don't enjoy the boring grunt work of putting the final
| polish on, but I work with people who prefer to put the polish
| on an already solved problem. This is a win-win as both of us
| avoid things we don't like. (note, putting polish on is at
| least 90% of the work, so I can't completely get out of that,
| and junior engineers never can). There are other problems that
| other senior engineers work on that I never touch - they are
| the experts not me
| moralestapia wrote:
| >"Ensure that you are fulfilling the expectations of your
| manager"
|
| "Just tell me what to do" is like the anti-senior developer
| philosophy, particularly if you report to someone who is non-
| tech.
|
| If you're senior you should be the one setting the expectations
| and lay out a (working) plan to fulfill them.
| lifeisstillgood wrote:
| Edit on the above: I am coming across way more negative than I
| planned. I just want to counter-balance the underlying
| assumptions that a workplace is somehow fair, or has your
| interests at heart. They are collectively controlling ~50% of
| GDP resource allocation, they are effective dictatorships for
| the executive "class" and perfect competition that would keep
| them in line is rare in most industries.
|
| Perhaps I am saying that changing the game is better for
| everyone than learning to play the current one well.
| groby_b wrote:
| Uh... Fulfilling expectations has nothing to do with making
| decisions on your own.
|
| I can guarantee you that no matter how good or bad their
| manager, if you don't meet their expectations, you are in
| trouble. By all means, own your local decisions, be proactive,
| keep your manager in the loop - AND MAKE SURE THEIR
| EXPECTATIONS AND YOUR WORK MATCH. That doesn't mean waiting for
| requirements, but that means your manager knows what you do and
| agrees, at least in broad strokes.
|
| Surprising your manager unpleasantly never leads to good
| outcomes for you. There's only one person holding power in that
| relationship. (Positive surprises do work, but they usually
| take the form of "I did what you expected, AND".)
|
| Totally agreed that the 1-2 days in the future thing is wrong.
| As a senior you should be _at least_ a couple of weeks in the
| future, better if it 's months. At the staff level, 6-12
| months. At the principal level, 2-5 years.
|
| If it's just a few days between each level, a) somebody is
| failing at their job, and b) yes, information will be outdated
| by the time it reaches you.
| lowercased wrote:
| > Surprising your manager unpleasantly never leads to good
| outcomes for you...
|
| Not quite 'my' manager directly, but a client's PM. They had
| a ... PM/PO type person who was quite insistent that we had
| to have feature X by date Y. Slightly aggressive, but...
| sure. Between that insistence (over weeks) and the date Y...
| that person left and a new person started.
|
| 4 days before a walk through (where new items were
| demonstrated to stakeholders, and company owners), I sent the
| completed functionality over to the new PM (he'd been there a
| few weeks, but obviously still... new). "looks good" he
| replied. I checked that he'd at least watched the video I'd
| sent over.
|
| Demo happens and I show the functionality, with the "this is
| vital to have" from the previous PM. Silence. Then "we didn't
| know that was being worked on". Behind the scenes I was
| somewhat thrown under the bus, even though I had jira
| tickets, paper trail, video evidence and assorted other info.
| "Lowercased is ... subverting the process" and I made a whole
| team look bad. Even though... they all had signed off on what
| I was delivering. But behind the scenes, new PM had told
| people "feature X won't happen" (i have _no_ idea why that
| was said) but apparently I made a lot of people look bad,
| because I 'd delivered something they said wasn't going to
| happen.
|
| So so so weird...
| groby_b wrote:
| Well, yes. Shitty management still exists. And the power
| imbalance is always there. I'm not saying not surprising
| your manager guarantees good outcomes, I'm just saying
| surprising them guarantees bad outcomes.
|
| The lesson I've drawn for myself from similar incidents is
| "know all the stakeholders, and talk to them".
| Consulting/client work makes it extra hard, because
| stakeholders just keep coming out of the woodwork :(
| lowercased wrote:
| I'm not sure how much more I could have communicated.
| "Feature X is done and i'm going to show it on thursday".
| "OK looks good".
|
| Behind the scenes, without telling me, telling other
| stakeholders "feature X is not being done".
|
| Demo feature X.
|
| "Whoah, you really blindsided us and made people look
| like they don't know what they're doing".
|
| Had this been, say, 5 weeks ahead of time, yeah, maybe.
| This was ... 3 days? Monday afternoon to Thursday
| afternoon - maybe you could count that as 4.
|
| This had grown to the point where I wasn't allowed to
| directly talk to the major stakeholders. This demo
| meeting _was_ the time to talk to them, for a dog and
| pony show only. 18 months earlier we had more regular
| (still in a group) communication, but it was possible to
| talk directly. As this grew, my own ability to talk
| directly to people was layered with middlemen, which
| exacerbated this sort of problem (had happened before,
| but never for something this 'important').
|
| What's... funny about all this is that the earlier PM had
| made this feature of paramount important, but it turns
| out ... no one is using it.
|
| EDIT: both at the time, and now, I looked at it as
| "mistake". we're human and things happen. but it was
| framed as "lowercased was hiding information, working in
| secret". this was not the case.
| lifeisstillgood wrote:
| The power imbalance fascinates me - why should it exist
| at all?
|
| Do as I say or else? Why not, credible mission, great
| story telling, compelling vision, a well argued
| rationale.
|
| I mean. If we paid everyone UBI, then every compmay would
| look a lot like the Linux Kernel (insert preferred less
| shouty FOSS project here)
| setr wrote:
| Because communication is inefficient.
|
| If you have to produce a well-reasoned argument, and
| successfully convince all peers that your argument is in
| fact well-reasoned, and comprehensive, and handles all
| concerns of all involved or potentially involved, and
| that all opposing arguments do not meet these criteria...
| it will take ages to get all stakeholders in agreement,
| and even when you do, you get a horse designed by
| committee (a camel).
|
| Projects with no owner consistently end up in the same
| rut -- always planning but never doing. Bikeshedding.
|
| So you need the owner. But for someone to own the
| project/task, he needs to be in charge of it -- he needs
| power. For what is power if not the ability to make a
| decision and have others follow through on it?
|
| In arenas without defined power relationships, but manage
| to produce useful work, it's usually the case that the
| power relationships still exist; they've just been made
| implicit. You see this in geopolitics, in your high
| school group projects, in Valve, etc. Determined not by
| corporate hierarchy, but instead charisma, money, social
| networks, physical/military strength, etc. Most of which
| is reflected by the corporate hierarchy anyways.
|
| Businesses just make it explicit, and consider it
| valuable enough to attach higher pay. You might make the
| argument that managers don't deserve higher pay than an
| individual contributor, but it's clear enough that a
| manager has much higher potential impact than an IC -- if
| you manage 100 resources, making them 10% more efficient
| than otherwise, you're doing the effective work of 10
| ICs. But in my head, a resource-managers role is
| primarily to make his team more efficient -- by
| optimizing processes, clearing blockers, umbrella'ing
| against shit from on high, reporting upwards, to guide
| the overall direction of all involved -- not to dictate
| the every individual activities of his underlings.
|
| Also the Linux Kernel clearly has a power hierarchy, and
| while that power hierarchy doesn't dictate what you work
| on, it does dictate whether your work can hold any value
| (by getting included into mainline). The difference just
| ends up being in the fact that it really doesn't cost
| anyone anything for you to continuously do work that's
| ultimately rejected every time, whereas for a business it
| obviously does (in the format of your salary). Obviously
| you can fork if you want and make it perhaps valuable...
| but you can exit the hierarchy just as well in business
| by quitting.
| bluGill wrote:
| > You might make the argument that managers don't deserve
| higher pay than an individual contributor, but it's clear
| enough that a manager has much higher potential impact
| than an IC -- if you manage 100 resources, making them
| 10% more efficient than otherwise, you're doing the
| effective work of 10 ICs
|
| Maybe. Supply and demand is always at play. If any
| manager can make 100 developers more 10% more efficient,
| but only a few people who have any ability to be a
| developer at all, then the developers are worth more.
| Numbers are relative to supply - my company has
| discovered we have to get ICs better raises than their
| manager at the lower levels as our great developers were
| becoming managers. We can get managers from lots of
| different entry level areas, but not enough engineers.
| setr wrote:
| > If any manager can make 100 developers more 10% more
| efficient, but only a few people who have any ability to
| be a developer at all, then the developers are worth
| more.
|
| Then you'd expect fewer developers, and fewer managers
| overall. Unless you hit some really low threshold (e.g. 5
| developers, so the same manager is only worth 50% an IC)
| where the cost of manager doesn't "pay back" in
| developer-headcount-reduction, it'd still follow the same
| strategy.
|
| And of course, the amount of "pay-back" you get from a
| manager would naturally be how one derives their value,
| and thus their paycheck.
|
| But IC --> Manager as the only promotion track is
| completely unnecessary, and generally a mistake. That's
| just intentionally driving into the peter principle
| (promoted to the level of their incompetence), because
| you've simply left no other way to go. Usually you have
| the alternate track for IC's expanding into larger/more
| abstract/more important domains, but not head-count;
| technical/solution architects and what-not.
|
| But the story hasn't changed -- if you assume the role of
| the manager is to make their resources more efficient,
| then a manager's value scales with the number of
| resources under him; an IC does not. It will always
| eventually make sense for a manager to be more valuable
| than an IC, and this only holds false at low headcounts.
| groby_b wrote:
| I mean... if you get your managers "from lots of
| different entry level areas", then you get exactly what
| you paid for.
|
| Any tech manager even remotely worth their salt should be
| able to function as a senior+ IC if necessary. If that
| skillset is lacking.. maybe you want to rethink your
| hiring. You'll likely never see the effect of a good
| manager if you don't.
|
| As for your argument that developer scarcity somehow
| makes managing worth less - the opposite. If you can hire
| a single person that can effectively give you 10+ devs
| without having to hire those 10+ devs, you want to hire
| that person.
|
| And for the "ICs need better raises, or they turn
| managers" - uh, no. But you do need to offer parallel
| development tracks, with comparable advancement
| opportunities. (In reality, IC & mgr raises should be
| roughly similar in terms of percentages. If you value
| managers, at least)
| bluGill wrote:
| Management is not related at all to tech ability and
| there is no reason for a manager to have tech knowledge.
| Tech knowledge avoids some of the worst things i've had
| managers do, but my best managers have been completely
| non technical.
| lovich wrote:
| The military also has a peculiar behavior of punishing
| leadership for failures instead of promoting them or giving
| them a golden parachute. Telling engineers to fulfill the
| expectations of their managers is more of survival advice.
|
| Granted this does not hold for 1) small startups where everyone
| has influence on the direction of the product and bureaucracy
| hasn't taken hold yet, and 2) FAANGS for the most part appear
| to operate under military like organization and allow for IC's
| to make decisions without 12 levels of approval.
| draw_down wrote:
| [deleted]
| [deleted]
| pojzon wrote:
| Based on the job title only - Ive met seniors that would not be
| even called juniors in other companies.
|
| So yea.. it all depends where you stand.
|
| Ps. You dont have to compare yourself to others. Ppl will do it
| for you. During interviews or internal reviews. You wont run away
| from that.
| giantg2 wrote:
| "The first--and most important--thing is to stop comparing
| yourself with others. Ensure that you are fulfilling the
| expectations of your manager and team for your development
| contributions."
|
| I have yet to see a manager or organization that doesn't compare
| on some level, even if it's just implicit biases.
| michaericalribo wrote:
| No doubt. But It'll be a more favorable comparison to you if
| you are focused on achieving your manager's expectations, and
| proactively contributing to the larger org -- not comparing
| yourself to others as your personal performance metric.
|
| It's obvious when someone is contributing to the organization
| in good faith / trying to do their job well, vs trying to edge
| out a colleague in specific eval criteria to look better. The
| second is not a good look, but I highly value (and reward) the
| first.
| giantg2 wrote:
| That hasn't been my experience. I've even had managers pit
| devs against each other.
| michaericalribo wrote:
| Those sound like bad managers :/
| giantg2 wrote:
| I guess so. I haven't had a truly good one out of the 19
| or so that I've had in 10 years.
| lupire wrote:
| If your manager is churning every six months, they are
| either bad managers or in a failing organization.
| giantg2 wrote:
| Yet somehow they go on to manage other teams and thr
| company manages trillions in assets.
| triyambakam wrote:
| Where I am often hung up in comparison is due to age. I dropped
| out of college and spent my early 20s learning agriculture and
| construction. Now I work in software engineering and my current
| manager is younger than me. Not only is he younger than me, but
| he's been able to climb up to an engineering manager in a shorter
| amount of time than I've been working as a SWE. So I feel really
| lame - wasted so much time early in my life and still seem to be
| wasting time.
| Ironlikebike wrote:
| > he's been able to climb up to a engineering manager in a
| shorter amount of time than I've been working as a SWE
|
| If you want to be an IC, don't short change your
| accomplishments. Eng Mgr is not a promotion from IC, it's a
| career change.
|
| The SWE career progression is much more established, and is
| often much more formal and understood than an Eng Mgmt track.
|
| Your younger manager has recently gone through a significant
| career change that requires a significant amount of self-
| education to advance further. It's possible he'll advance
| opportunistically (if there's a vacancy) or by being clever or
| political, but his competency will not necessarily advance with
| him without him putting a significant amount of effort into
| learning this new career.
|
| It's not uncommon for established SWEs to make more than
| engineering managers until the engineering manager has
| progressed to a level where they are dealing with levels of
| stress (business & social) that would make most people's hair
| fall out.
|
| Even then many companies have career tracks that pay as well in
| the upper echelons for individual technical contributors as for
| high level eng mgrs. The one thing they have in common is that
| there are very few positions at the top of any career ladder.
| It gets competitive. Hopefully your aspirations match your
| talents so that you can compete for those fewer positions.
| triyambakam wrote:
| Thank you for the perspective, that's very helpful.
| bckr wrote:
| Hey, I'm right there with you. I think this industry is skewed
| young, but not as much as we might think. For me, the redeeming
| quality of my early 20's is that I matured dramatically. I'd
| encourage you to take a good, long (I mean months long) look at
| your motivations over the last decade and find a way to honor
| the part of you that was curious about agriculture &
| construction, and find a way to bring that part of you to life
| in the here and now. The word for releasing the tension between
| being and doing is "play".
| nobodyandproud wrote:
| Management is a different job.
|
| I've been an engineering manager for over three years; and the
| skillset is completely different. So much so that I recently
| flubbed some easy LC questions.
|
| Businesses may treat it as a promotion, but don't make the
| mistake of thinking it really is one.
| rambambram wrote:
| Don't think like that. It might not have happened yet, but I'm
| sure in the future you'll be glad you can apply knowledge from
| agriculture and construction into your SWE role. And maybe not
| in your SWE role, but at least somewhere in your life.
| yourapostasy wrote:
| triyambakam needs to take this advice to heart. Software
| engineering shares many troubleshooting patterns with
| agriculture and construction. While the cross-fertilization
| isn't 100% efficient, it doesn't need to be to be effective
| because the bar fortunately doesn't demand a global maxima
| only a local one: fix the current problem in a business-
| acceptable timeframe and cost, and you're adding value. Onto
| the next problem.
| wainstead wrote:
| "The goal is not to be better than someone else; the goal is to
| be better than you were yesterday." (to paraphrase the Dalai
| Lama)
| lupire wrote:
| Don't compare yourself to others. Life is half chance. Find a
| good paying job and a good life.
|
| There is nothing special at the top of the ladder, just more
| money sometimes. Money isn't the only way to build a good life,
| and that's all money is good for.
| bobthepanda wrote:
| Right. There's always a bigger fish, so if you have imposter
| syndrome you'll never be satisfied. Best to ignore those
| ideas.
| deathanatos wrote:
| At one point I had a director of engineering who had something
| like 6 months of engineering experience; predictably ... they
| weren't great at the engineering. I wouldn't put too much stock
| in it just because your manager is younger than you. Now, if
| they're climbing the ladder because they're actually amazing,
| by all means, try to learn from it, but I've seen people on
| runs of the ladder just inexplicably.
| kevinventullo wrote:
| In your next 1:1, ask him how he did it.
| adra wrote:
| Ugh, one off data points are just as often wrong as they are
| right. What adage they give of their success could have just
| as aptly worked in reverse for you. Luck/timing (aka no
| strong correlation to actions) is a real thing, and are all
| too often ignored by the winners who always reward their
| achievements by "hard work" (clearly working hard is often
| needed as well to succeed).
| ghaff wrote:
| If someone asked me "You seem pretty successful. How did
| you manage your career?" my story would be (other than some
| generalities) perhaps interesting but utterly unactionable
| for anyone else. And that's probably not unusual for anyone
| who hasn't followed a pretty conventional path.
| kevinventullo wrote:
| Winners do this thing where they show the slightest
| interest in winning and a willingness to learn from more
| experienced people
| nonethewiser wrote:
| I've kinda had the opposite experience. I started my SWE career
| in my early 30's. I feel like I've been treated as if I have
| more experience because of my age. And to some extent, rightly
| so. We have substantial work experience compared to a 21 year
| old. I did not start in a junior role.
|
| Point being, don't blame your age. And don't underestimate
| yourself. And definitely don't compare yourself to others. If
| you are growing, then good fucking job. Keep doing that and
| maybe switch positions to somewhere more conducive to your
| growth if you feel like that's necessary.
| emaginniss wrote:
| Do you want to be a manager? SWE -> engineering manager is not
| a natural and guaranteed progression. It is a shift from
| individual contributor path to a management path. A good
| company will allow you to become a more and more senior IC
| (senior -> staff -> principal -> distinguished) without a
| requirement to become a manager to increase your pay.
| greenhatman wrote:
| Engineering managers aren't necessarily better than you. It's
| not necessarily the next step up. I personally prefer to stay
| closer to code.
| oxff wrote:
| Best time was 10 years ago, second best is now :)
| michaericalribo wrote:
| The reason the author says it so many times is because it is so
| hard to do in practice :)
|
| You have an opportunity to distinguish yourself. You already
| stand out and break the mold as someone with a nonstandard
| background, and it will get noticed--and treated differently--
| if you excel.
| nickflood wrote:
| I feel you on that, but in these moments I remember a quote
| from Steve Jobs: "You can't connect the points forward, you can
| only connect them backwards".
|
| Which for me means that you don't yet know what advantage these
| 'wasted' years could give you in the future. Just trust
| yourself to make the best decisions you can given the
| circumstances and you'll get to where you want in as little
| time as you can.
| javier_e06 wrote:
| The operative word is value: Many conventions and activities have
| value, some don't. I once met a senior developer who created in
| c++ the Class Byte for our codebase to tackle portability with
| it. I was a noob and I really thought that learning that had
| value. Years later I realized that there was really no value to
| the solution and it was more of a gold-plating activity. Yet,
| there was value on learning to recognize superfluous code. As a
| code developer their is that is that ironic and somewhat painful
| enlightenment along pacing along many dead end trails. What about
| those activities that truly not only do not have value but chip
| away the value of other valuable efforts. That is the time to
| dust off your resume.
| makz wrote:
| I've heard that the literal translation for Sensei is "the one
| that was here before" or something like that.
| kodah wrote:
| Being a senior engineer is weird when looking retrospectively. I
| remember being a junior and experiencing what the author is
| talking about with respect to puzzlingly staring at my seniors
| when they could answer obscure questions.
|
| Now I do it and do the same things they did with me: facilitate
| my thought and troubleshooting process rather than give me
| answers. I think the people that are successful in Senior+
| engineering are that way because of certain technical and
| character traits they've developed.
|
| One is a willingness to be _right_ in the long run. When I was a
| young engineer I would make my cases hard with data. As a senior
| engineer I sit back and let the machine mull for a while because
| I _know_ that 's what the engineering machine will do regardless
| of how technically right I may be. Another is knowing that
| _right_ isn 't always right. Sometimes the right answer is
| technically wrong, or the learnings of wrong need to be made
| before we collectively can be right. Another is a lot of
| patience; patience for myself, patience for others. I recently
| admitted I was behind on work because my power was out for three
| straight days. Young me would've found a coffee shop and worked
| those days with a single monitor down to the bone. Senior me took
| my dog to the park.
|
| Not everyone makes it to senior, had I not forked my path in
| certain places I don't think I would have. My advice, relish your
| time as non-senior and ask lots of non-technical questions. The
| technical stuff comes over time and by necessity.
| [deleted]
| GolDDranks wrote:
| > Not everyone makes it to senior
|
| As a someone who isn't a junior, having two years of game
| development (in-house game engine dev) and five years of
| enterprise (mostly web-based internal tools & some data
| engineering with big data) development under my belt, but
| hardly a senior either, what do you think as the alternative to
| not "making it to senior"? Asking out of curiosity.
| yitianjian wrote:
| Staying mid level. Although the "senior" title of yesteryear
| is closer to the "staff" title of today, even at the top tech
| firms.
| Test0129 wrote:
| Being in the "optimal zone" I think. The best dollar-value-
| to-expectations is probably at the mid-level. Senior+ you
| take on a lot more responsibility, need to know a lot more,
| and you're not always compensated for all that knowledge.
| Having been at senior and above for a while now I can say
| that the juice isn't always worth the squeeze.
|
| Nothing is wrong with optimizing for actual life things. It's
| hard to not be a company man when you reach the higher
| echelons. Generally, your real life suffers some. Especially
| since the invention of pagerduty.
| RobRivera wrote:
| strongly concur
| angarg12 wrote:
| Pretty much most big tech companies have levels Junior, Mid
| and Senior (and above). It gets confusing because many
| companies skip the mid level and call anyone with 1-2+ YoE
| Senior. However most often Senior eng at Big Tech is a bigger
| deal (think coordinating the delivery of complex systems
| involving more than 1 team). You could easily spend the rest
| of your career cranking up solid code as a mid level dev if
| you wished.
| dbttdft wrote:
| Weird how they used as an example debugging character encoding
| bugs instead of solving real problems as the typical thing
| software engineers do.
| kradeelav wrote:
| Not an engineer, but I find this translates well over to design.
|
| Seniority in a lot of ways feels like the acknowledgement of
| being able to utilize people/soft skills in order to build
| things. I find at least 1/3 to 1/2 of my time, a roadblock in the
| project is caused by accidental miscommunication from top down,
| and the faster you can debug those, the happier everyone will be.
|
| Personally I rather enjoy that hybrid of people and "hard"
| design, but it's definitely not for everyone.
| michaericalribo wrote:
| > utilize people/soft skills to build things
|
| I love this! It can feel frustrating to need to use these
| skills to exert influence: I sometimes feel disempowered by not
| having the full resources to throw around that I want.
|
| But that doesn't really limit my ability to do the work. I've
| just had to cultivate a different skill set. Persuasion, not
| coercion
| sp332 wrote:
| One of my classmates in college couldn't handle this. I'd glance
| at some awful Visual Studio compiler error and then point out a
| missing semicolon. He ended up feeling stupid, but I was trying
| to be encouraging because his code was pretty good aside from
| some missing punctuation, which will come with practice. He ended
| up switching majors.
| ThePadawan wrote:
| I find it really weird that this isn't a universal experience.
|
| I've been coding for 15 years and could not imagine myself in
| your classmate's place - but I feel _exactly_ the same while
| learning to draw.
|
| I try to draw a somewhat straight line or something at least
| resembling a circle, fail, and feel like it's completely
| impossible to me, be close to tears, and everyone who can do it
| might as well be a wizard.
| hnfong wrote:
| I think it _is_ a universal experience. That 's why you're
| (presumably) a programmer and not an illustrator.
|
| Most people naturally choose to focus on things they are
| relatively good at, instead of keep banging their heads on
| something they struggle at.
|
| GP's comment seems to imply it was a negative experience for
| the newbie, but in all probability given the daily
| frustrations and chaos of software development in the real
| world, switching majors might actually be the "right"
| decision for that person.
| ThePadawan wrote:
| > I think it is a universal experience. That's why you're
| (presumably) a programmer and not an illustrator.
|
| > Most people naturally choose to focus on things they are
| relatively good at, instead of keep banging their heads on
| something they struggle at.
|
| My parents told me I had to get a degree - they had very
| little appreciation for art, and some appreciation for
| engineering, but 0 understanding of computers. So I
| enrolled in CS so they would get off my back. Before
| college I had written maybe 50 lines of C.
|
| I was never particularly good at CS - I just did OK enough
| under the pressure of having a clear goal (a degree) and
| there being no alternative to success (definitely not
| moving back in with my parents. I would have preferred
| joining the foreign legion).
| wccrawford wrote:
| I find that egos can be really fragile when people are just
| starting to learn things. Pointing out the mistakes so quickly
| can seem like a great help (and it is!) but some people react
| like they're staring at the sun.
|
| Instead, I find it better (except for how long it takes) to
| walk them through finding the problem as if it's really hard
| and just nudging them to the steps they'd need to take to find
| it themselves. They learn even more, and it doesn't immediately
| show the difference in skill between you and them.
|
| At the very beginning, even a small difference in skill can
| seem like a _lot_ to the lower-skilled person.
| Swizec wrote:
| Show a person the bug, you're on the hook forever. Teach them
| how to debug, you're needed less and less.
| deathanatos wrote:
| Easier said than done, I've found. "Check the logs." is a
| statement I have to utter far too often.
|
| Admittedly, when I started at the present company, I also
| remarked "this logging tool [Sumologic] is pretty difficult
| to use". The response from my senior engineer at the time
| was "it really isn't that hard." and then she didn't answer
| the question I had and made me figure it out on my own. It
| felt a bit brusque at the time, but it was _very_ useful in
| the long run. I did end up figuring out how to query Sumo
| (I still maintain that its UI is gawd awful), and that 's
| enabled so much debugging.
|
| I think I also ended up authoring our internal
| documentation's page on how to effectively query in Sumo,
| which I feel has been read never.
| didgetmaster wrote:
| Even very senior engineers can make simple mistakes that can
| bruise their egos. Several years ago I was called into the
| office of the chief architect. I was also a senior engineer
| with a lot of experience, but he was quite famous (at the
| time) in the industry for his technical skill. He was
| convinced he had found a compiler bug. He had some c code
| that he had traced through the debugger at the assembly
| level. It was something like this:
|
| if(/ _some really long boolean value with AND and OR clauses_
| /); { /* some code to execute if TRUE */ }
|
| He was sure that the if statement was FALSE some of the time,
| but the code inside the brackets would always execute. He
| spent more than an hour pouring over the code.
|
| It took me a few minutes before I noticed the semicolon at
| the end of the if statement. I'm sure he felt stupid when I
| pointed it out.
| marcosdumay wrote:
| > I'm sure he felt stupid when I pointed it out.
|
| He certainly did. There is no amount of experience that
| makes people not feel stupid about those. What changes is
| that you learn to not be affected by it, because you know
| that it's not a personal flaw (at least not one specific to
| you), and while you can improve on it, you can't completely
| fix it.
|
| But the alternating between feeling like the dumbest person
| on Earth and the smartest person on Earth never goes away.
| jersak wrote:
| In those situations i do feel stupid but also feel
| relieved. Fixing a semi-colon is easier than fixing some
| major logic flaw that could have way deeper and worse
| ramifications.
| didgetmaster wrote:
| I think it happened enough that some newer compilers
| actually post a warning message when it is encountered.
| Just like switch statements when you don't have a break;
| statement for every case: clause. In some cases you want
| the logic to fall through, but it can cause havoc when
| you didn't want that and you just forgot the break.
| ghaff wrote:
| You develop tunnel vision and, whether someone points it
| out to you or you look at it with fresh eyes in the
| morning, it's a head slap "Duh."
| gregmac wrote:
| Yep. I've learned over time to just walk away from
| problems like this that make me go "that's not possible!"
| or "there must be a compiler bug!"
|
| After at least a few hours away (ideally not coding) your
| fresh eyes will often spot it.
|
| Similarly, demoing the bug to someone else is a good way,
| and often through the mere act of demoing it you'll find
| it yourself (also known as "rubber ducking" [1]).
|
| [1] https://en.wikipedia.org/wiki/Rubber_duck_debugging
| ryandrake wrote:
| Or just better software development practices that can
| eliminate whole classes of bugs. If the developer was
| instead in the habit of not putting huge expressions
| inside if() statements, he might have caught it himself.
| Consider: bool condition = /some really
| long boolean value with AND and OR clauses/;
| if(condition); { /* some code to execute if TRUE */ }
|
| Two advantages of doing it this way:
|
| 1. It's much easier to notice that incorrect semicolon
|
| 2. Even if you don't, you can stick a breakpoint (or log)
| between when condition is set and when it is evaluated,
| to convince yourself it works.
|
| 3. All modern compilers will produce the exact same code
| as they produce with it mashed into the if()
| didgetmaster wrote:
| I agree. It also really helps when you want to negate
| something.
|
| if(!condition) is a much better read and less prone to
| errors than trying to negate a long statement inside the
| if().
|
| This pattern also eliminates duplication. I have fixed
| bugs in code where the same long if condition was
| duplicated several times within the same function
| (probably with cut and paste). This wastes cycles
| recalculating it each time and runs the risk of changing
| one of them without changing them all.
| kbenson wrote:
| Some people are lucky enough that the things they focused on
| early in life are things they were good at. Unfortunately, I
| think some subset of those people also develop an aversion to
| things that they don't appear to reach competence in as
| quickly as prior endeavors.
|
| That's a shame, because often I think people that have
| competence in a subject come naturally to them end up at a
| disadvantage later, because their foundational knowledge is
| lacking (at least in cases where that's possible and learning
| was self driven).
|
| One example of this is learning a programming language
| through doing compared to actual study and research. By
| "doing" I'm not referring to a project to cement details, but
| for example how most people know bash.
|
| Another example would be spoken languages and some of my
| college professors. I'm not sure I ever heard anyone speak
| with as good of a vocabularity and diction as one of my CS
| professors that English wasn't his first language.
| hnfong wrote:
| I find the opposite. If you know how it feels like to learn
| something you have a natural talent for, and you know what
| it feels like to be struggling, then you can choose to
| focus on the things that are most "efficient use of your
| time". Especially considering that life is short.
|
| Of course, you can always choose to learn something you
| aren't best at, but at least you know the trade offs (i.e.
| needing to spend relatively more time to reach the same
| level of competence as more talented person).
| bluGill wrote:
| I'm not convinced there is such a thing as natural
| talent. (there is such a thing as lack of talent) All the
| greats are just average people who focused until they
| became great.
|
| You just have forgotten what it is like to be a child who
| knows nothing. I've been speaking English since I was a
| toddler, I'm learning Spanish now and I make tons of
| mistakes and often can't understand even a basic sentence
| - but in fact I'm a lot better at Spanish than I was at
| English when I had equivalent amounts of study into
| English.
|
| Once you are a minimal level of competency it is a lot
| easier to study as well. So if you have only a tiny head
| start you will be top of your class, and that is always
| more enjoyable.
| stevenhuang wrote:
| The concept of a thing called G factor shows there is
| such a thing as a natural innate talent.
| fullsend wrote:
| In my layman's view it's obviously a balance, like all
| things. Look at the top athletes - Michael Phelps has
| more upper body than he does lower. The best UFC fighters
| often have insane wingspan for their height (and
| therefore reach for punches). Usain Bolt is not a short
| man. Certain people are tuned for certain things. Then
| whether they combine that baseline with total obsession
| and hard work is up to them.
|
| The mental sphere is where it becomes super vague for me.
| Did John Von Neumann just study really hard? The
| anecdotes told about Feigenbaum of Chaos Theory make him
| sound like a savant among savants. They just kept that
| childlike curiosity? Doesn't make any sense to me. It
| seems they are tuned differently.
| danaris wrote:
| > I'm not convinced there is such a thing as natural
| talent. (there is such a thing as lack of talent)
|
| ....That doesn't track.
|
| If there is such a thing as lack of talent, then "talent"
| is just "not lack of talent".
| metadaemon wrote:
| I think one of the quickest ways to make life easier and less
| stressful is to try to ignore the ego as much as possible.
| dieselgate wrote:
| Easier said than done, no? I think one of the defining
| qualities of an ego is deceiving the individual into
| behavior - ymmv. But that's why failure, psychedelic
| experiences, and more are important (imo) - for keeping the
| ego in check
| akiselev wrote:
| Sure, in the same way that "surviving to old age" is
| easier said than done. It's true, but what choice do you
| have?
| dieselgate wrote:
| Indeed. Parent post did mention "try... as much as
| possible" and that seems appropriate.
| thegrimmest wrote:
| Kill the ego. The less allowance we make for hurt feelings
| the more we can live in a world devoid of toxic ego-driven
| politics. We should all carry the expectation that
| professional criticism be received professionally.
| zibby8 wrote:
| Perhaps this is really stupid and juvenile, but the show
| Adventure Time had an episode where one of the characters
| said "sucking at something is the first step to being kind of
| god at something." I think that's an important lesson a lot
| of people should learn. Going out and sucking it up is
| awesome if it means you're getting better at something.
| soco wrote:
| On the other hand, toxic positivity sounds exactly the
| same. So which is one and which is the other? What to do
| when you suck at something? Persevere or pivot? Both are
| praised in TED talks, but you just can't pursue them at the
| same time.
| bluGill wrote:
| > Persevere or pivot? Both are praised in TED talks
|
| For good reason. Wisdom is recognizing which is correct
| for the current situation. There is no rule that applies
| to every situation. You have to make a choice and stick
| with it. Sometimes that means you try something decide it
| isn't for you. Sometimes you try something and even
| though you hate it, someone needs to do it so you keep at
| it - of those sometimes you will turn out to love it in
| the long run sometimes it was just a job. (it seems to me
| the only people who actually hate it are justifying a
| mid-life crisis that turned them to something new - if
| the mid-life crisis hadn't worked out they would have
| returned and been happy)
| zibby8 wrote:
| Sucking at something is the first step to being kind of
| good at something. It's impossible to not suck at
| something new, unless you are a prodigy. Whether or not
| you want to persevere in the face of prolonged sucking is
| a personal decision.
| didgetmaster wrote:
| There is a old prayer that goes something like:
|
| May God grant me the courage to change things that I can,
| the patience to endure the things that I can't, and the
| wisdom to know the difference.
| kevinventullo wrote:
| I find slow-walking someone through a problem can sometimes
| come off as condescending.
|
| I take a different approach where I immediately point out the
| issue, and if they get discouraged about how fast I solved
| the problem, I remind them that I've spent hours banging my
| head against the same issue. They will probably run into this
| same issue again, and get stuck again, but next time they'll
| figure it out faster, and the time after that a little
| faster, until it's basically instantaneous. And then when
| they're instantly able to solve a problem for a newb, they'll
| have to give the same explanation as I'm giving now.
| idontpost wrote:
| The circle of life!
| danielvaughn wrote:
| Hm, that's an interesting way to look at it, though I don't
| like framing it as ego fragility as that seems unfairly
| negative.
|
| I've reflected on this point quite a bit because I really
| struggled with it when I was teaching myself how to code.
| It's _extremely_ demoralizing in the beginning, because of a
| couple of root causes (IMO).
|
| 1. We place a lot of cultural value around "genius", and we
| often ascribe that quality to programmers, mathematicians,
| etc. While some of them undoubtedly are, it's not clear what
| that genius actually is, and a great deal of people
| mistakenly believe that they don't have the "right brain" for
| it, or are not "smart enough", because they don't feel like
| geniuses. When you make several mistakes when learning a new
| activity, every mistake reinforces that perception.
|
| 2. There are two relationships you can have with technology -
| that of a consumer , and that of the provider. As a consumer
| of technology, your perspective is that "technology works",
| and if it doesn't work, then something went terribly wrong.
| But once you become a _provider_ of technology, that
| perspective is flipped. Technology is broken, and if it
| works, then something went wonderfully right. It takes time
| to develop that perspective, and so young engineers will have
| their programs break constantly, not realizing that "broken"
| is the default state of the world, and in fact now their job
| is to make things work. Of _course_ it 's broken.
| tvanantwerp wrote:
| Something I once heard that I think is kinda true:
|
| When something goes wrong on the computer, there are two types
| of reactions: I am wrong, or the computer is wrong. The "I am
| wrong" person is discouraged and never gets very good at
| computes. The "computer is wrong" person persists until they
| bend the computer to their will.
| co_dh wrote:
| I put semicolons at the beginning of line.
| impjohn wrote:
| Found the chaotic neutral DnD player
| electrondood wrote:
| Part of being a software engineer is constantly feeling stupid.
| Until you realize this is normal, you're going to feel bad and
| have imposter syndrome.
|
| If it were easy, everyone would do it and it wouldn't pay as
| much. It's supposed to be uncomfortable in the same way that
| exercising at the gym feels uncomfortable. Thinking is effort.
| duxup wrote:
| When I did a coding camp a while back it was the folks who
| could handle errors... and kept typing/ trying who did well.
|
| Local football coach often says "failing is progress":
|
| https://youtu.be/0q3jiUrg7vY
| drummer wrote:
| Seniors are overrated. Principles is where it's at now.
___________________________________________________________________
(page generated 2022-09-13 23:01 UTC)