Hacker News Reader

Comment by jedberg | Hacker News Reader

> How to explain a technical concept behind closed doors to a senior person too embarrassed to openly admit that they don’t understand it

This list should also include: How to admit you don't know something as a senior engineer and learn from junior engineers who are closer to the new technologies.

As a junior engineer I found that I respected senior engineers more when they asked me to teach them something they didn't know.

As a senior engineer I feel like I get a lot more respect from the junior engineers when I just admit, "I don't know that can you teach me more or point me at some good resources?". For that matter, I get a lot more respect from other senior engineers when I give them exactly the same response.

View on HN

That's a great one. An observation that I've made over the years is that junior engineers tend to shy away from asking too many questions, afraid of appearing incompetent, whereas the most senior engineers asked the most questions. At a certain point asking questions becomes less about informing yourself, and more about informing the team (through context shared in meetings, chat). It can even take the form of the Socratic method, using questions to bring others to conclusions that may already appear obvious to you. Much better approach than pushing an idea directly onto others, and leaves plenty of room to change course as a result of the conversation.

> junior engineers tend to shy away from asking too many questions, afraid of appearing incompetent

Very true! And if they see senior engineers asking questions, they will hopefully feel more comfortable doing the same.

I would love to see a similar list for junior engineers.

Yes me too!

Yeah, I’ve also gotten a lot of mileage in the last few years using the emotional version of this. Instead of listening to a proposal and saying “well that obviously won’t perform fast enough” I’ve started saying things like “I love this but I feel nervous that it might be slow once you have it working”. The difference is subtle but important, because I’m being clear I want them to help me dissolve my fear about the performance issues. We’re on the same team in a way we aren’t if I make it confrontational.

Oh, that’s good.

I've been doing something quite similar. But sometimes I just get ignored, taking my "I love this but I'm nervous that" as "I love this".

I think about it like you have a volume dial that you need to turn up or down depending on the room you're speaking in.

If you're pretty junior, or you work with a lot of loudmouths, you might need to turn the volume up higher to make sure you're listened to. If you're senior, or talking to a group of people more junior than you, you can get away with being a lot softer with your words. (And you often should, to avoid intimidating the juniors). And its not really about volume. Its about your word choice.

Low volume: "Hm, that sounds ok but I'm worried about performance."

High volume: "This will be unworkable because of performance problems. We need preliminary benchmarks, or a plan for solving those problems before we can move ahead."

Maybe. At the same time I think most senior developers have been through the hype cycle a few times. Junior to intermediate level devs seem to jump on the latest "silver bullet" trend quite a lot not realising that this happens all the time and probably isn't anywhere near as good as the hype.

I miss working with adults who know not to take the first version personally. To me the difference is not so subtle, the first version is an engineering conversation, the second one is somebody who is clearly pandering.

When I started my career in software testing 20 years ago, the Socratic method was my best friend. It's a great way to lead a developer to a bug. Instead of getting defensive, they're extremely motivated to fix it.

> How to admit you don't know something as a senior engineer and learn from junior engineers who are closer to the new technologies.

(For reference: I've been paying my bills with code for a good 20 years now.)

I've learned 80% of what I know about Javascript, Typescript and React from one dude on my team who was freshly out of university. The dude was (and still is) a damn genius at that stuff.

If he doesn't burn out by overreaching, he'll be a legend by 2025 =)

Same. I’ve been at it for 20 years and just never was in a job that used React or Typescript. In my current job I was paired with a boot camp grad probably ~15 years my junior who has been an amazing mentor as I learned React + Redux + Typescript.

I learned sass from an intern we hired.

Emphasis on if he doesn't burn out.

Yea, he was (and still is) the kind of person you need to force to take vacations.

We literally took away his work laptop and disabled his office key access so he wouldn't work during his summer holidays :D

That was me, though perhaps less proficient, until I realized that all the work was basically worthless trash and there's little point in putting my employer before my own interests. Now I can't figure how to do that again!

Happens to me all the time.

I have decades of experience, but there’s often stuff I can learn.

Here’s an example: I have developed an SDK, with heavy documentation, but I have found that written docs aren’t actually very useful, as no one reads stuff anymore.

So a new engineer on my project showed me Postman. Before, I’ve used far humbler REST explorers. In turn, I showed him Charles Proxy.

I’ve actually gone way beyond what he needed with it, because it’s a great tool.

It is not a 100% replacement for my docs, but it will help a lot.

I can develop an architecture that is way beyond anything he can do, but it’s worthless, if he can’t write stuff that uses it.

> I can develop an architecture that is way beyond anything he can do, but it’s worthless, if he can’t write stuff that uses it.

A line from another article posted to HN today I remembered is:

"An API without a reference implementation and command-line client is called a gray box."

I totally agree with that. If your API/SDK has an easy way for me to copy/paste some code or command line examples to "play" with it, I'm about 1000% more likely to take it seriously.

In my experience being humble, I most frequently get

“Whaaaaaaaaaat you never heard of that, its so popular, everyone’s into this”

I just wait patiently and stare, maybe an occasional “ah, mmm”

and then eventually say “so can you tell me about it”

and really the answer is no, most people can’t articulate themselves and provide filler instead

it’s usually in relation to anything someone is passionate about, or an assumption they have that supports their passion. such as a social norm or ideal, not just engineering

Anecdote (which serves as a reverse example i.e. senior asking a question):

We were having a regular status call and since the meeting finished early there was a general chit-chat happening.

That is when we started talking about "iphone" and our boss innocently asked "what is iphone" (it had been on the market for a year since its first launch)

We started looking at each other in disbelief. But we knew this about her. She used to openly ask in a meeting without shame on things she did not know. But once she understood something she use to process that info very well.

The team really adored her because she was so good in other managerial things (like defending team, good rapport with individuals, planning, etc).

Back story was that all her time was spent with her 2-3 kids leaving no time for other things.

Key takeaway: stay humble. In my career, I have been antiquated in the past (Flash developer), so I have learned that going to someone and asking what they know is usually a better path. I also call out good contributions from other teammates, because that is what being alive is about.

This.

In the cases where I've been welcoming new individuals into teams it has always been made clear to them by me that there are no stupid questions, everything can be challenged if the argument for it can be made and that I don't know everything and wont/can't come up with all the ideas (ie they could very likely come up with a good idea to a hard problem).

In my experience this has really made it a pleasant experience to introduce new developers (fresh from uni or new to the code base/domain) to the product and team.

Just for context, in the country I reside in there isn't this emphasis on titles in the software space, and as such I am not a formal senior dev at my company. I believe I would have that title if living in a country where such distinction were normal.

But there s also the tendency we all had as juniors to try to push new things we're closer to, rather than try and accept the "old" technology often working just as well while being much simpler.

Not always the case, but when you see people pushing heavy, runtime-script languages full of ambiguity to modernize an old simple compiled code base, it's hard to do the wait and see and show 2 years later to the juniors: "see your lombok spring thing is now absolutely unmaintanable when all it does is 3 multiplications"

It s often a balance since nobody likes change, junior like senior, and often both sides have their crap.

I’m pretty sure this extends into all roads of life. Being able to admit you don’t know something instead of acting like you is a good trait. At the very least people won’t look at you and assume you’re completely full of shit.

I think that just about the whole list applies to people who are more senior in their roles - not just software engineering (of which I know little).

The best example of this is pair programming with someone for any length of time. No one has a proper subset of knowledge it is is immediately apparent and both sides value the exchanges.

And often the interactions themselves are the teachers. My mind was blown when a particularly bright child asked me what's the difference between a dream and reality. The best I could come up with is that this 'reality' has a larger continuity and is the one that people in this large continuation agree to call 'real'. I don't know what I could have said if he mentioned a recurring dream with a continuing state. I did say that boils down to a label assignment in case it that should ever come up.

My favourite definition of reality is the stuff that doesn't go away when you stop believing in it.

This makes reality a social phenomenon, beyond just physics. For example, institutions are a reality because many people believe in them; the police don't go away when criminals stop believing in the law.

If you get enough people to believe in your dream, it can become real, self-sustaining. Neil Gaiman wrote a nice short story, taking the idea literally - A Dream of a Thousand Cats.

The implication is that your dreams never involve any of these things.

I don't understand this comment. Is "the implication" from my comment or the parent comment? Is it the dreams I talked about, or the dreams that the parent comment's child interlocutor was talking about? By never involving any of "these things", are you talking about institutions?

To be more verbose, by "institution" I mean stable, recurring patterns of behaviour (much like https://en.wikipedia.org/wiki/Institution), which isn't that far off of the continuity point made by the parent.

> How to admit you don't know something as a senior engineer and learn from junior engineers who are closer to the new technologies.

Definitely! This is something I do a lot and love to do. I’m excited when i realise “oh, rather than reading and reading in this topic - I can ask (a person who happens to be junior) if they’re not too busy”.

Everyone learns off everyone the whole time.

The actual problem in that case (when you need a closed door for something like this) is that you are part of a team without trust and you senior staff has not yet learned how to make themselves vulnerable.

It depends on what you're asking about. I remember an older engineer asking me what the term "amortized analysis" meant and that made me write him off as someone who doesn't know basic CS concepts (he was still a great product engineer, but I never once went to him for technical help afterwards).

In hindsight, I guess it's sort of forgivable given his age. The topic probably wasn't even invented yet so he couldn't have learned about it in school.

Everyone has blind spots. I have a PhD in computer science. I wouldn't think any lesser of someone's technical chops if they weren't familiar with the term, so long as they quickly understood it when explained.

Seems ignorant to me, but what do I know? I've never studied or used amortized analysis either.

I'd never heard that term, so I looked it up. I was definitely familiar with the concept, but never heard that term for it before.

Not everyone learns the same terms for the same concepts. Maybe you should be a little more accepting that not everyone had the same education you did.

I am curious, what other name does it go by? I had a strong response because this came up while arguing about the cost of appending to a vector in loop. He had no idea what I meant when I said it was "constant time amortized" and didn't seem to know how resizable array work. This is always the first data structure you learn in CS 101 so I am surprised people are disagreeing that it is basic CS knowledge.

Honestly, I've never heard a term for it. Just talked about in the abstract:

"That operation is O(n log n)"

"Sure, but that operation doesn't happen on every loop, the entire algorithm is still O(n)".

It reminds me a bit more of talking about p50 vs p99 latency times but where we’re not measuring production data, more like what we’re guessing production loads will look like.

I'm old enough to remember that Microsoft got this wrong back in the early 90s. In early versions of Microsoft Foundation Classes, which Windows C++ programmers were using before the STL took over and std::string became the thing, repeatedly appending a character to a string (I think it was CString) was quadratic, because they didn't increase array size by a multiplicative factor, but by a linear amount, so you'd get a ton of reallocation and copying. I used to use versions of this as an interview question.

However, language for concepts evolves with time, and younger programmers shouldn't assume that older programmers don't know a concept because they learned it by a different name. (Though they might not know the concept).

In early versions of Microsoft Foundation Classes … repeatedly appending a character to a string (I think it was CString) was quadratic, because they didn't increase array size by a multiplicative factor, but by a linear amount, so you'd get a ton of reallocation and copying.

I remember seeing production code slow to a crawl once because of that one. It wasn’t long after I’d left university, where I’d studied CS but the lectures on complexity theory had seemed quite theoretical at the time. Suddenly, here was a vivid example of how it could cause a problem in practice, in a situation as everyday as putting some text in a UI. The solution — using a string builder — then led me to several other principles about choosing an efficient internal representation for data and it being OK not to convert that data into its “true” form until you’re ready to use it. I suppose I should thank whoever made the original mistake, because despite causing a frustrating afternoon with a profiler, it also created several lightbulb moments early in my career.

You likely have lots of colleagues that never completed a CS degree.

Knowing the generally used names of things isn't the same as knowing the things.

"All science is either physics or stamp collecting." -- Ernest Rutherford.

I suspect there are many people who understand the Big-O, Omega, Theta, and Little-O implications (the physics) but might not have heard the term "constant time amortized" (the stamp collecting).

(Not that knowing accepted names is bad, it's much much easier to communicate when everyone shares a set of terms that they agree on the meaning of...)

Had another great quote from a professor: every introductory course is fundamentally a language course.

I have an MS in Computer Science (from the mid-90's) and have never heard of this term. (it seems simple enough once you read the definition of it).

My graduate level algorithms class used average or probabilistic cost, but never the term amortized.

What’s the difference between “constant time” and “constant time amortized?”

Replace "amortized" with "on average" and you'll have the basic concept.

A constant time operation has bounded runtime for every input, but an amortized constant time operation can allow for much longer runtimes so long as they happen sufficiently rarely. Concretely, doing an amortized constant time operation N times should be O(N).

It sounds like "amortized" is close to mathematically meaningless in that case.

Why not use actual statistics jargon at that point?

Sometimes we need to realize that the reactions of people inside of the software community are almost purely due to their own personal (usually social) insecurities and are not worth addressing.

We have an entire thread giving credibility to someone who absolutely idiotically dismissed another person for not knowing the meaning of a single word.

The person who was temporarily ignorant of the meaning of that word is not the one I am thinking needs to be ignored here.

To expand on @hansvm answer, an example would be a hash table.

Insertion is O(1) (constant time), most of the time.

But once in a while the collection will need to increase the size of the underlying array, which causes the entire table to be reorganized. That specific insertion will then be O(N) (where N is the size of table). The good news is that this reorganization happens only once every N insertions.

So amortized insertion is O(1), even if in the worst case it can be O(N). Depending on your use case you can hand wave the worst case away with "amortized it's constant time", or you can choose a tree instead, for a more predictable O(log N), or you could use some other mitigating tactic, like initializing your hash table with enough storage _for all use cases_ so you can guarantee O(1).

Just a data point: I could guess what you meant by “constant time amortized” but I’ve never heard of “amortized analysis”. I’ve learned the same concepts under “big O notation” or just “complexity”.

I suggest that you consider whether it’s possible that other people know the same concept under a different name and don’t write them off as quickly if they don’t know your favorite term.

Amortize is what you do with the loan on your home; never heard that particular word in this context.

I am surprised at how blithely you assume the terminology you learned at your particular college is universal, and how parochially you seem to look down on people just because they don't share that particular terminology.

Don't conflate knowing the term with (really) knowing the concept. Some people might know what you're talking about even without having ever heard the term.

One of the most substantial, frequent mistakes I see from junior developers is writing off the skills of their colleagues because of perceived gaps in knowledge.

Counter-point: I had never heard the term "amortized analysis" before (I am self-taught) but when I looked it up, I realized "oh I've done this kind of thing before" and immediately understood what it was.. I just didn't know this kind of aggregated profiling had it's own name...

So my advice would be don't be too quick to judge people based on assumptions you make about them.

Reply on news.ycombinator.com