IT takes more than explaining why java has a no pointer exception when the language doesn't have pointers. To be a great engineer, this is soft skills engineering. Epo de four thirty five. I am your host, dave smith. I am your host James and dance soft skills engineering as a weekly advise podcast for software developers who just need little help explaining logically inconsistent statements in programing languages.
you can never escape pointers. They're always there. They're just lurking out of sight.
I guess you could call that a link language doesn't add pointers. Guess what? Yes, IT does in its run time it's written .
and sea yeah exactly.
And maybe there's some kind of mythical I was here about list machines and I don't quite understand what that means. Besides, they use lip a lot. Maybe there's some mythical other type of architecture that doesn't reference to addresses in memory under the hood, but I don't know what IT is.
Doesn't use memory that only .
you have IT just doesn't use memory IT is random yeah stateless, totally stateless and equal yeah IT only IT looks at the wonder's zero and decides is the next thing.
I won zero. And I make fun of the peer functional periods because they got nothing on this machine.
I've created the perfect computer. IT is a single piece of paper with a one and a zero written on IT pledge stateless, purely functional.
You always gives the same results given the same input or any input. Yes.
let's get out here. I got to think our patrons, thank you so much to ten print. Lucas smarted is cool.
Go to ten. Nick moon, you are per two, per two with little music emotion. Es attribute air, none type has no attribute to string.
Have your guns ali, ted timbre. I found some cash on on, back on the list, baby, become a senior engineer. 点 com unsalted french fires are morally objectionable than from drone deploy。 Chase w.
norton. Level up your type, type of types of that. Dev never is not just a created on mars. Flamingo OMG, I like chicken. I like liver amicis miami s please deliver trash panda kill boss cancer dots nevar is not just a plan in the vulcan system janey own charter this token tic t helicon dot A I best observably tool for A I red pandas best panda types ript is a microsoft conspiracy.
JoNathan king is now beautiful, functional user documentation IT takes more than setting a funny name on patron to make dave and James and left to be a great engineer. The creator William ago, that net lord regnar travis britten canes john grant, if you would like to join the celestial ist crew. Dave, don't loss over this bit.
Maybe it's different. Good to kills down and that cuts off. And a special shout out to code sale, who has generously given a large sump in order to support the good work we do.
Thank you. So thank you. Cody is the ka booth .
testing the limits now of the patriotic me field up.
You found him. How many characters? That is, i'll let you count IT up. yeah.
A jam is. And I want to thank our response or for this episode, the episode sponsor by work, or O, S, which is the best way to add single sign on into years of our product. You'll hear more about work O S, in the middle of .
our show today. Dave, you only read our first question. I do.
This comes from a listener named song body. Ah ha, first, I recently listened to epsom one seventy eight parenthetical note huge backlog of episodes work through and they've made the assertion in twenty twenty that forty seven percent of all companies would be remote by twenty twenty three, wildly close. What else do you see in the future? Right answer, wrong reasons. yeah. okay. Now onto the real question.
I work like that. Can someone, can someone go Cherry pick all the things that i've said that turned out to be right?
I recently looked through our backup, our episode st. I didn't find any.
Oh, OK my strike back from the record. okay. Second question.
my question. My work situation continues to confound and external insight would be helpful. My boss and I have a long working history going back to an entirely separate company. I am a high ownership, high drive, principal level individual contributor, and feedback has been lackluster. Take away from last year's performance review would be best summarized as quote I agree with yourself review, end of message.
Oh.
i've been working to quote manager up and mentor or reverse mentor, my boss, but he always makes snap decisions and then refuses to evaluate after presented with more info, coupled with his biopic view of our team scope and general preference for speaking only and not much action, i'm trying to figure out how to get where I want to be without burning an old and history ally, very useful bridge. I want to work on big technical problems instead.
And the fact of manager of a team I managed to before and did not enjoy being responsible for people as a principle and responsible for their output somewhat. But if they underperform, I work with their manager and them to prioritize and do upfront work to instantiation ze their investment in what we're doing. Help examination are.
oh, I agree with yourself, review your end of message. I didn't know that was an option. I know right.
You could say reviews a lot easier going forward. Yeah, this is this is hard. I feel like i've been in the situation, I assume is sort like you're doing great.
Keep IT up and then they don't even have to read yourself for you because it's probably if you're if you're high ownership principle engineer presumed ly, you have thought of some great feedback for yourself, very insightful. So really yeah do those good KPI. I think whatever .
you came up with is pretty good to see next year. This might actually be a symptom of the long term relationship that this person has with their boss because the boss has grown to trust them so completely that they're like, look, I know you well, I know you Better than you know yourself. I don't need to review your work. I trust you.
They also could have arrived that like old married couple age where they just they know nobody y's going to change, you know like why but why bother giving feedback. They're still gna put their slippers on backward whenever IT is right or not.
Exactly that could very well be. Listen, i've known you've ten years. I gave you I stopped giving your feedback on your curly braces a long time ago.
Yeah, IT didn't work. The feedback didn't work, so i'm done. IT also could be like you're so close that it's hard to give critical feedback that happen sometimes in some relationships where your your friends and you don't want to upset the friendship by saying, hey, you are doing a bad job at this thing best. So right, so you don't have in a feedback and you also are the manager of this team in a way that you don't want to be and you feel like your boss is kind of not doing anything and has to small of scope vision. There's lots going on here.
Yeah I kind of sense that this person wants too much from their boss like you're viewing your boss as a critical success factor when in reality you could probably just be successful without your boss helping you. And in fact, what I have found is that the more senior you become and in this case, i'm interpreting principle level to mean pretty senior, the more senior you come you become, the less a management structure is actually a designed to help you and b actually helpful.
Yeah which makes sense. I mean, if if it's a tree, most of the nodes are the bottom of the tree. So most of the management organs set up to manage where there are the most people, right? You can just do things.
I think that's the summary of your advice. Just go do stuff. Then there's something you want to do is doing pic view of our team scope and general preference for speaking only and trying to fear how to get where I want yeah just go do stuff you're trying to help manage. Other people say, hey, I have this other project and really passionate about, and i'm gna focus on that. I think that's the best way I can have impact as a principle engineer.
exactly. And and do don't hold yourself back because you're not getting quote feedback from your boss. I think that another thing that happens as you become more senior is that feedback from people like especially your manager becomes less valuable than the the signals that surround you that tell you if you're doing a good job like is like especially your principle, level, individual contribute. Like i'm assuming here that you have your work dict ates where the company is going technically and you will see the results of your work in the success of the company, not just in the business metrix, but in things like cost savings and things like bug rates. In things like developed a productivity like this is where you need to start looking for feedback to tune your work because at this point, you might be the only one who actually has that visibility or even understands the work you've done to understand .
what the impact should be. Yeah, yeah, I like that. I like your idea that you don't you don't need to depend on your boss very much. And at this level, to its sort like a peer relationship, more everyone talks about how their parallel tracks management in ice.
And it's kind of true and away and kind of not true because there's still poodle named s but usually as you get to be a very senior I C, you might have a boss still. But you you're like A I don't know you're like a uh uh cou tenant or something. Some dumb military return that I don't understand um that I will just make up on the spot less like you are a supported reporting directly to them and taking direction from them.
So if if you don't love the vision of your boss, good news that's a big part of the role of a principles er helped to find the technical vision of team or organ company. So that's fine. You can just say, hey, here's what here's what I think the vision is.
Let's go to IT. Yeah I mean, I just kind of thinking like try to scale this thinking up and like let's go up to the C T. O. And go to the CEO. Who does the CEO get feedback from? Well, I guess you could say the the board of directors and the investors give the city feedback, but usually that, that feedback comes in only two forms either a here's a check for the equity that we're paying you out because you've been so successful or be your fired like they don't know .
ah it's it's binary. I mean.
don't get me wrong, the board of directors in the investors are often in very interested in mentoring and guiding the CEO, but typically they hire a CEO, not because they want to mold and shape them, but because they already believe in what the CEO is doing and they want to let them free. And and they hire, they invested in that person because of who they already are. And so yes, the mentorship and guidance is definitely valuable.
Don't get me wrong. But that CEO, the main source of feedback from the CEO, is going to be the business outcomes that they're striving for, like basic things like revenue, like are the company is the company actually making money. And the closer you approximate that as you move toward that, the less and less you're going to get feedback from others and the more and more you're going have to find IT yourself. I feel like a maybe I just repeat myself, there are a fair bit, but I just one of the say the thing about the CEO having final feedback only.
what about this piece of i'm responsible for their outputs. I work with their manager and helps them prioritize and do a front work to incentivize their investment. And what we're doing, just like this piece of sounds like they don't want to do IT though. Oh.
I got I kind of got the impression that even though they don't want to be responsible for managing people, they understand that as a principle engineer, they are responsible somewhat for people's output by giving them good things to work on and helping managers manage their people by providing feedback on their people. I guess I didn't really read that as A A major problem that they see to me.
That sounds like they're saying i'm doing too much of this stuff ah like it's it's too much like I feel like i'm the manager of this team.
yeah. Well, to that, I would say the things that we're listed here, so I am responsible for their output somewhat if they underperform. I work with their managers and I do a framework to incentivize their investment in what we're doing. These are very much important bullet points on the job description of a principle engineer. So if you don't want to do that job, then maybe you don't want to be a principal engineer.
Yeah, IT still might be taking up more of your time than you would like. And I think you can shift the proportion of time that goes towards that. I I think I agree with you that increasing the output of other engineers is a big part of the job, but maybe you can time box IT somehow you can delegate some of that.
You have your your army of staff engineer peones, the lovely staff engineers that all look up to you. Hopefully, it's not only your responsibility to make to support under performing engineers. So if you do if you want to do less of IT, there are ways to do that. Yeah like .
just stopping IT like yeah .
just saying no, do you just do you just schedule say, great, I have time two weeks from now or what don't know yeah time box how many hours you spend on IT and then you kiss stuff up and then they go somewhere else. Or I do kind like the idea of delegating some of this if it's makes it's a very senior engineer than you're the best person to help them. But you shouldn't be just in the weeds meddling with every performance issue with every individual contributor yeah so maybe you can help culture, train or or ask other engineers that are also senior to help with .
this yeah so I mean, I am when he says, I want to work on big technical problems. And instead of doing all these people management stuff to that, I say big technical problems tend to be solved by big groups of people, and the people element just can't be separated from IT. So I actually kind of think we might have a little bit of an expectation problem here.
The biggest technical problems I know of were solved in coordination with lots of people, and that means to get to the people stuff. So I don't know. Yeah maybe reset expectations a little. Well, have you answered the question?
I think maybe there's one one remaining thing, which I think is how do I manage the relationship with my boss, who I perceive as a long time friend, but also someone who standing in the way of me getting what I want. And so that I would say A I already said maybe what you want is not actually perfectly aligned with what you should expect for the job that you're doing. But even setting that aside, I think that this is this is you know many situations where we advise people to go talk to someone and say, here's what you should say to them.
This is a situation where I don't even think a conversation is necessary. I mean, your boss seems to be standing in your way, but i'm not really sure he is, and I don't really, really know. If anything, you need to tell your boss, I think you are the owner of your own destiny here, and especially at such a senior level, go do what you want to do.
I don't know. I mean, it's almost like this person's holding on to some of the mentality of how things were when you were in a more junior role and you are expected to come to work and kind of do what your boss said every day. But I really don't think that's what you're how your boss thinks you need to work now, especially the I agree with yourself review and message.
Bit like your boss is not really interested in managing you. So great, take that as a signal that you are free to do what you want. I like IT. You've answered the question.
I I degree uh, brilliant, James, is that I just want to randomly tell you this important fact that I have worked for three companies that have built their own s soo. Implementation and these are some of the biggest mistakes i've made as an engineer that's for shadowing. We want to tell you how to avoid this mistake.
Yeah IT does seem straight forward at first. But then you remember there's oof, idc, saml skin r back, a bunch of other aconites that you only find out about when you get aged. And some of these .
acronyms, you don't even know what they stand for, but you are responsible for them. Okay, yes, this is where work O S comes in. Work O S makes IT easy for developers to add s soo and other enterprise features to their APP, rather than building IT from scratch yourself.
Actually use work cos where we're right now. And they have amazing dogs. They are kind of developer.
Facing stuff is great. They got example s and a bunch of different languages. No, just python. PHP go. It's, it's nice. yeah. And sometimes .
people worry, well, do I actually get to maintain control over my U I. And yes, worker s provides a log in UI toolkit called off kit, which uses radix themes, which are open source. And so you actually have tons of customized service over the look and field.
a drop in replacement for off zero. And this gives you really great pricing.
one million monthly active users for free, one million.
And I feel like to my muster, I that recently.
worker s acquired a company called warrant that provides fine grained authorization and robed access controller are back fg, a and r back for those in the know. So this means that worker s can grow with .
your needs over time. Do not punish h your future self by building a homegrown sso system in many companies that are using workus today, like versus web flow perplexity and loom. You can check IT out at work O S docs. That's work. O S dot com.
Would you like to read our next one?
Yeah, I would. This is from an anonymous listen, who says, what do I do when my teammate proposes a new architecture or framework in a new project? IT might solve some existing problems, but has a high chance to create technical that and make on boarding harder for new engineers.
How can I convince them to use the existing solution while still helping them feel comfortable sharing their opinion next time if I follow their suggestion and things don't go well, how can I convent them to reactor the structure without them feeling like i'm blaming them? Um yeah, this is interesting. This feels like right on the edge.
I don't know. This is right in the will house. The show feels right on the edge of technical and non technical softie proposes a new architecture framework in a new project.
The main question I see here is how do I shoot an idea down without cutting off the idea factory for future ideas?
Yeah, I think you can say that this I feel like this is a theme that i've been harping on for the past few months. You can just say the thing that you're trying to do directly, explicitly instead of implicity do IT you can say, hey, I don't think we should do this hopefull. You have some reasons that you can articulate, but you can also say explicit I want you to still feel comfortable sharing your opinion next time because I just because I disagree with this doesn't mean you shouldn't speak up. And I I I feel like we come to Better decisions when we talk through different alternatives and disagree .
and then work things out. Yeah, I agree. Hit confront ad on I disagree with this idea, and I wish you would never speak again.
That is I mean, that can be the the subtext that some people take away. Communication is just so hard. And the more explicit you can make IT, the easier IT is you can interpret that someone is offended by you saying stuff.
They might interpret that you're mad and you disagree with that and think they're dumb for proposing IT or yeah that the more explicit you can make IT the Better. Um I am assuming that you're in this opposition to to actually kind of put your foot down. Hopefully, hopefully you have discussed why they want this.
And have you feel like you understand their reasoning and could explain IT to them in a way that makes sense to them? Hopefull, you're not just kind of like new jack shooting IT down because IT is scary. A new 嗯。
i'm going to assume by the fact that they took the time to write this question into our podcast that they're not having a nature reaction to this.
It's just a very slow needs. They have the slowest reflexes in the world like a gentle have been here with a little hammer on the nee. And then several weeks or months later, I think this one is from twenty twenty two actually.
So this is several years later. Oh, IT just kicks out to know where are they? Like, walking down the stairs. Oh yeah, this is a common problem.
And I, I got to say, my I I applaud you for thinking about the other person's feelings when you shoot down an idea. That's great. I mean, you you have reasons for believing what you believe about this.
And you could just say those and leave the leave the other person subject to just interpreting that as maybe a personal front. And I gotta tell you, I hear about this probably once a month, I discover that someone told themselves a story about something that someone else said or did, which was just not at all true. And IT kind of makes me sad IT IT IT makes me worry that i'm not actually able to say anything, any other human being, without something being filled in that I didn't intend, you know, yeah.
And I hear IT. I don't I don't know if I do this, I try, I really try not to do this where I like, look, just take the facts as presented. I really don't want to fill in the story gaps with things about how you feel about me or, uh, what your true motives are, any any of that stuff. I'm just like, look, I just go with the facts and I ve got to tell you is a much more stress free way to live.
I lean into the opposite direction where I I build up this rich fantasy world and give it's so exciting, full of intrigue and drama, huge shifts of alliance yeah, great battle is entertaining to live in. Yeah.
battles being way on the stage of your mind.
Yeah, did you see how they slightly hesitated before they open the door for me, the knife in the back is coming soon.
I can tell you've joined to .
the other side unless a double agent.
Yes, you're trying to portray yourself as the other side.
trying to signal to the opposition. okay. Yes, that's why I did swinged them.
That's why I gotto talk to H. R. After this podcast. Oh no, that yeah that makes a lot of sense. I I don't think I do that very well that don't .
interpret things wrongly. Yeah yeah, that's because you're .
very creative.
I think that's part of IT like i'm not actually that creative to think of a back story. I'm just like all I know is what they did. I don't have any other ideas about this.
I feel like I am somewhat empathetic, which also is like leaning into this of like interpreting signals from people in telling telling yourself a story about why they are doing things, or how they might feel. I think that does make IT harder in some way. So I had no idea.
Now it's gone. Well, while you're thinking of that, I have an idea. So when I feel compelled to shoot someone's idea down, I one thing that I found that works really well is as you're describing the idea or a you're making your case to the person um try to show that you have objectively considered IT by listing all the good things about the idea and not just the bad things this will signal to them that you've done your research and you're not just shooting IT down for some other dumb reason like I didn't have the idea.
For example, you can say, look, I like this new framework that you've proposed. IT has the following advantages. IT looks like IT will increase developer velocity in the long term. That looks like they'll be easier to hire people that work in IT. IT looks like it'll reduce our deployment speed, you know, whatever IT is.
And then you can say, but there are also two cons that I think out way all of the pros, and they are A I think it'll make IT hard to on board new engineers and they will creates some technical debt. So in in the aggregate, when I combine, when I compare this list of rozen coins, I think the coins out way the pros. And if you show someone that you're really thoughtful IT, then they actually have a chance to say, okay, I can I agree with that because maybe they didn't consider the cons that you were thought of. Maybe they only thought of and IT also gives them a chance to say, oh, as long as we're listing all the present cons, here's a couple of process you didn't think about and that might give you a chance to reconsider your position with now more complete information and see if the scales tip back to a more affirmative answer than a negative yeah what .
about the second part? If I find the suggestion, but things don't go well, how can I convince them that to the structure without them feeling like a lame them? I was reading a wikipedia article the other day about some british statesmen who had some with, he says, or something I don't know, and he wrote a book about some historical event, they got disputed by the people.
And then he joked for a while that he was going to write a second edition after some new evidence that came out. That was I, I told you, so you fools, that was the title of the second edition of the book. ounds.
right? More explosives in there. And so I think that's what you could do you you could make like we've talked about architectural decision records before. I don't know writing to communicate technical decisions, you write a memo that's title I told you you for .
exactly what's this wicky beijing in the company corporate wicky cold. I told you, you fools.
Why are they? They like fourteen of them.
Part one.
yes. List of grievances.
yeah. I mean that maybe that won't go so well. You know, IT is so hard actually, once a decision like this has been made, especially when IT comes to bringing in new frameworks and stuff like this or architectural changes in your code base, IT is so hard to get him out. So I would say this is actually a situation you're never going to face where you'll need to actually convince them to reactor or restructure IT without feeling like your brain.
You will never be given the .
option would .
never have to do this good news.
You will never clearance from your product managers spend time on IT.
okay. That's yeah you're saying IT doesn't matter if you convince them you to convince the business and you want so don't even try, right?
That's what so you can still I told you so fools article but it's not gna matter.
No one we will read IT.
yes yeah. And that's why it's so important to make good architectural and framework .
decisions up front. I think that's also why, especially in an established place, folks tend to be kind of conservative about architectural decisions.
And I mean that in the sense that kind of slow to introduce these things, slow to change the way things are done, slow to add new variants of like we do at this these five ways at a sixth way because they kind of know and and it's here forever once we added that's a little more pessimistic than the truth. And you can make a business case for IT. You can kind of chip way stuff over time, but IT is generally a lot harder to remove or change stuff. And IT is to add IT yeah, which I think is why I don't know you could bring that up in party or cons at the beginning because if this goes wrong, we will never ever fix IT.
right? It's a one way door, right? I mean, that's a common amazon decision making framework. It's like one way doors deserve more scrutiny. I'm not scrutinising you, but this is an important decision that we will not be able to go back on.
Yeah, IT feels such a bomber to say this that feels like it's a larger problem with technical decisions are in general a one way door because they are not there's nothing inherent in the code that makes IT a one way or it's more like the the priorities of the business make this .
so one way so reality ah economics yeah I actually had a yeah I had a customer who is the kind of a high dollar value customer that paid for little custom offered development back in the day and he is to make a joke where he'd say the difference between hardware and software is that you can't change the software.
My father in law works in hardware and he does iterate a lot on these little boards that he's well, little I don't mean that in a dismissive sense. They are very tiny. These boards that he's building a lot of changes .
yeah um that's because you can change hardware.
Yeah well, have you answered the question? I think so combination of make .
sure you fully explore the prosy on the coins and show them that you've done so and then understand that certain decisions are actually very hard to revisit. So it's important to you make them right up front. And I was I was laughing when I said, you'll never actually be able to restructure or reject to this, but it's come like eighty percent true.
And so when the time comes and you actually are able to do IT, hopefully it's Christal clear to that person why we're doing this. Like your arguments against this framework, they will either prove to be true or false, and it'll be demonstrable, you'll know, based on things you can actually observe. And so hopefully they're observable by the other person as well.
And hopefully they're a rational human being who hasn't completely tied their ego to the to this particular web framework that you chose. And if so, you're they'll be like OK, let's go and kill IT. But i've actually been there before.
So we had let me to tell one brief story little over ten years ago, I joined the company. IT was a startup. We had A A bunch of of code. And an early engineer in the startup, p had chosen to use a particular framework to do permissions enforcement in our web application. And IT was IT was probably a little overkill for what we needed.
And no one really understood IT well because he was kind of a magic, the thing that just kind of happen in the background and exceptions would just be thrown here and there when when someone stumbled upon A A permission thing that they weren't allowed to do. And this we wanted to tell IT out. So when I say we, I mean, pretty much the rest of development team, which is like four, five people.
And so I did not handle this well. I think I just assumed that everyone agreed with me. And that was true for everyone, except the person who brought in.
And we never really had to sit down conversation where we said, he, we like to debate the merits of this framework. Can we remove IT? But we eventually did tear IT out, and more or less without this person's knowledge.
And so I think that that there may have been hurt feelings, that we're completely avoidable if we had SAT down and had a person to person conversation and been able to actually explore the whole situation together. That was an example of when he goes bad, and that person eventually left the company, and I felt bad about the way the whole thing went down. And I wish that I had just SAT down with them and said, listen night. I don't like this. And I want to explain to the good and the bad as I understand IT, and see if you have .
a different opinion on IT. Yeah, IT is truly hard not to get tied up in your own technical contributions in code. And especially if you work somewhere for a while, you will work there long enough to see IT become a monster.
Then then everyone kind of complaints about the current state things and it's so bad, it's so horrible. And teams can be Better and or worse at noticing um the author's presence or or kind of being careful in their language to to try to heart feelings. But IT in general, if you works more for a while, you will build something incurred by everyone else, including yourself, sort of, and and it's that I know tricked and noga agree, but necessary. That's what the money .
for that .
make you feel Better. Tears away with pile cash, right? right? We answered IT, I think so. What could people do? Sorry, forgot to wish them good luck.
Yes, you know what day's good luck is? Sufficent o it's powerful enough to count for both of us. What can people do if they want their own questions? Answer.
go to some skills, the audio and click to ask your question. But then we want to say, thank you, everyone who does that each week. We love, love reading your questions. They fill our heart with joy and luck. luck.
Yes, that's why I think they put a little spring in my step.
I could tell, I could tell from the .
zoom call sounds spring here. Thank you so much for listening. Thank you for asking questions. We will catch you next week.