Speaker 1
I mean, we don't really know,
Speaker 3
at least I don't, what your background is other than Android. What other skills do you have that allows you to step into other technical roles? I know you do have other ones, but for the listeners, what are those?
Speaker 2
He plays the trombone really well.
Speaker 1
I do play the trombone. That was not a factor in my interviews, unfortunately. I like to swim also not a factor.
Speaker 2
Ah, damn it. No,
Speaker 1
I mean, I think my whole theory when switching a job, from switching tech stacks, was that the nuts and bolts of day-to-day programming, like knowing how a constructor works in one language versus another, knowing what kind of frameworks to use or how to use them correctly. Like, that's just a small part of your job. There's so many other elements to it, such as communicating with design and product and figuring out what you're actually going to build. Just architecting the solution that you're looking for, like how do you build it in a way that's maintainable and that actually works? Being able to debug code quickly or like, I don't know, there's so many skills, especially with like being a senior developer, those sort of skills that you get don't have as much to do with like the day-to-day nitty gritty of coding. They have more to do with like interpersonal relationships and reviewing code and mentoring and stuff like that. And I figured all of that would transfer wherever I was going, as long as someone else would give me the chance to learn their tech
Speaker 2
stack. So John Carmack, one legendary developer, Quake ID from the previous times, you know, like previous, yeah, I mean, hopefully folks know who John Carmack is, very celebrated software engineer. This was in the context of, there was a tweet that he recently posted. This was in the context of, hey, with all this AI stuff, writing all our programs, you know, does it mean that we are relevant as software engineers, right? And he alluded to something very similar, right? So I think what he said was software is just a tool to help accomplish something for people, you know, and many programmers like fail to understand that for a long time, you know, if you keep your eyes on, you know, the delivered value and don't over focus on the specific of the specifics of the tools of the programming language, you're kind of safe. Like, and I think that goes, that resonates pretty well with what you're saying, which is like, hey, just writing the actual code and knowing the language, knowing the syntax and being able to write it is an important part of the job, but it isn't actually the biggest chunk of, you know, why software engineers are paid so well these days, right? Because especially as you progress to the senior levels, the other aspects become much more important, right?
Speaker 1
Yeah, it's not the hard part. And this is something I've said about GitHub co-pilot when it came out and chat GPT now, which is that they solve what I kind of consider the easy part of the problem, which is like figuring out the exact syntax of what you're trying to express. But it's figuring out what you want to express in the first place that's always the headstumper to me, but it's like, okay, what, like, a good example of that I was just working on this morning, what API design should I use? You know, I've been working on backend stuff now. Someone, one server is going to talk to another server over HTTP. Like, what parameters should I allow them to send over? Should I be more restrictive? Should I be more unrestricted in terms of what I accept? And that's, that's not something that like an AI or the whole co-pilot can answer for me.
Speaker 2
I think that, that really sums it up pretty well. Going back to what you were saying, right? So I just had a question around like, when you decided, okay, hey, I'm, you know, climate tech, that's basically where I want to go. How did you start with that process? And how long did it take?