Hacker News Reader

Comment by top_kekeroni_m8 | Hacker News Reader

Senior level developers are usually people with excellent domain and business knowledge. How does one get a senior programming job without knowledge of the field? I might consider myself a senior in my current job, but I wouldn’t necessarily call myself that when applying to a new field.

View on HN

IME autonomy is the primary measure of seniority. If you need mentoring, or are completely uncomfortable being told "I don't know, can you figure it out please?" then you definitely have an opportunity to grow.

There's a third kind of learning in software. The first two are technical and domain, the third is abstract application and adaptability of your skills. That latter one only comes from experience. How do you efficiently learn both tech and domain? Can you identity waste (time and/or resources) early? Are you resourceful when seeking information? Are your questions and discussions phrased in ways that maintain direction and brevity? So on.

>IME autonomy is the primary measure of seniority

What if you're autonomous by heart, but the software is so huge and poorly documented, as well as having lots of bureaucratic rules and gripes, that you pretty much can't be autonomous? That's a reality for many developers, junior or senior.

I think in that case it’s still a case where as a senior you should figure out how to be most effective in that situation, push for a change, take leadership and convince others.

>push for a change, take leadership and convince others

Oh yeah just stage a grassroots political takeover of the engineering team, no biggie, I'll get right on that. Doubt anyone will have any issues with that.

That's exactly what senior behavior looks like, and is what propels you to the next level.

This is also, in many companies, what the lead up to an internal blacklisting looks like, especially when said company has a dysfunctional technical management. Entrenched players (competent or not, mostly the latter) who may have been involved in the original iteration of a software project and/or architecture in many cases do not take too kindly to someone who is willing to rock-the-boat and challenge their authority.

I'm a big believer in doing the right thing but all I say is tread carefully because you can and will get burned if you do not take into account the dynamics of a company's internal politics.

This is absolutely correct, and so is parent. Like any ambitious endeavor, done well it leads to success, and done poorly to disaster.

Or you find another avenue to address the same concern. Or you find better evidence to support your position. Or you mitigate against bad priorities and be patient until it's obvious that the bad decision isn't paying off. Or you talk to different people to see what you are missing.

Or you find another problem or assignment without this category of problem.

If you tried all that and still aren't making an impact, go pitch that story as you apply for a position with more empowerment.

That is quite literally what senior developers need to do. Not only performing well, but convincing others of the soundness of the design. This may involve a mutiny.

Some of the best changes I've seen took this path (client/server to web; prem hosted to cloud; n-tier to API) since the entrenched engineering team was not making appropriate design decisions.

The idea that you can't be anonymous in such a situation is a "junior" attitude.

The "senior" attitude would be to find ways to achieve autonomy and improve the situation. They would either succeed or determine the company doesn't actually want a senior person in that role and move on.

In talking with senior people who have been in such situations, you hear stories about their valiant efforts with partial or full results. When I talk with junior people, you hear about complaints and wishes but little action beyond their own work.

“Either change your environment or change your environment”

If you are truly a senior developer in any major metropolitan area in the US and kept up with the market, it shouldn’t take that long to find another job.

Sounds very "no true Scotsman" and people are taking this way too senior vs junior. If you are a junior wanting to become a senior or prove themselves as being more than junior, but find yourself in scenarios where management isn't actually asking for a senior but a rockstar, domain-expert medior going under the title of senior, what do you do? Continuously hop jobs until you get lucky? Wait until you finally rack in enough years so society deems you worthy of senior? Most situations I find myself in don't want to be fixed. Trying to take charge comes across as trying to tell the driver how to drive, or take the wheel myself, when its their car we're riding in. And using my own car is akin to starting my own company or going contracting.

>The "senior" attitude would be to find ways to achieve autonomy and improve the situation. How is this a "senior" attitude anyway? This should be the default attitude of any self-respecting employee, and I personally had this mindset from day 1 of my career. Who in their right mind wants to be either dependent or not make their life better? That's not junior, that's lazy.

The needs of a senior engineer vary by org and culture. It's only a "no true Scotsman" thing if we insist that there must be a single objective definition, but such a thing is a total myth. I've hired devs with the senior title that barely kept up with college interns. Similarly I've seen folks with 5+ years fail to meet expectations for baseline engineer with clear coaching and PIP over 6+ months, leave the company and land their first "senior engineer" a month after being fired. I've seen senior google engineers who failed to thrive in an open-source stack since they were used to being hand-held by Google's internal tooling and wealth of expertise they could turn to for any issue that was outside their immediate wheelhouse.

Within a company it's possible to have some standard, and a lot of companies work very hard to make their levels as objective as possible, but even then it's incredibly difficult to reduce a large set of diverse individuals working on diverse projects with diverse skillsets down to a single number.

All that said though, it doesn't matter how good your technical skills are, if you can't unblock yourself with cross-functional efforts, or figure out a way to optimize a bad situation, you will not be considered for the fast-track in most large engineering orgs. If the situation you find yourself in is truly intractable as you suggest, then the senior mentality would be to cut your losses and find a new situation.

The code is the documentation. If you can run it through a debugger, you can figure out what it does. You may not know why it was written that way. But, someone in the organization knows.

Edit: corrected poor phrasing

> But, someone in the organization does.

…if you’re lucky.

You mean: Someone who used to be with the organization knows, but they were let go three generations ago when the management fired the developers to move development to India, then fired that outsourcing organization to move development to China, then fired the China team and brought you in as a temp.

Then you assume the source code is the spec. If you are brought on as a temp even better. You’re probably being paid either as a 1099 or W2 contractor and thus are billing by the hour. You get paid for trying to disentangle the mess.

> but the software is so huge and poorly documented

This is the case in FANG companies. The expectation is that you figure out how to effectively find the info (whether by finding the key people, reading code, etc). Since finding info takes so much time, it's also expected that you make good judgement calls on what info you research (as you cannot be proficient in the entire codebase).

As for development - same thing goes. You find & form the right partnerships and have convincing enough arguments that people work with you on a project. Finding people that also benefit from your work is called "alignment" (of objectives).

You know how a lot of engineering comes down to making good choices about trade offs? Could be speed vs memory, could be which language or API to use, could be keeping it simple vs anticipating likely future needs. Same thing goes for working with an organization or codebase that has sub-optimal aspects. You think about and pick which, among many axes, is the most impactful thing to push on and you just do it. If the software is huge and poorly documented, write the docs you want to see for the parts you work on. If it’s a big tangled mess, pick somewhere to start unwinding and just find a way to make some sort of progress. If you do this, and you have a healthy org, it will become a natural reference point for others about how to do things well.

If you are instead saying that you feel no hope that work will be valued or recognized, you need to decide either to do it anyway (because you are someone who’s going to think and do the right thing, ie, lead) given the imperfect reality we live in, or you can decide to find a healthier org to work in. By healthy, I just mean more functional and well organized, and thriving in a field of sufficient resources — similar to what you’d think of in a healthy biological organism.

So you might feel constrained by the existing language, build systems, release process, etc compared to working fully autonomously, on the other hand you can accept them as they are, gently advocate for ways they could be improved, but spend most of you energy on the things you can directly affect. It’s like gradient descent — push every axis towards improvement but push hardest on things you can improve the most. If you do this over time and don’t silo away too much, you will naturally gain more influence over time (again assuming a reasonably healthy org).

A pattern I see over and over is good engineers doing exactly what you suggest, writing those docs, filling in the communication gaps, and then being told they’re not “technical” enough for their role, or a promotion, or a raise.

It sounds nice in practice, and I really wish it were advantageous in more places, but there’s a real risk. That assumption that you’re working in “a reasonably healthy org” is rarely safe to make.

This doesn't line up to me. We they told that by a technical manager, or non-technical manager?

I don't think a technical manager would ever make that statement, and I don't think a non-technical manager would care.

Then throw your hands in the air and say that whatever business problem your company is trying to solve, well, they'll just have to deal with it?

No. Autonomy here is figuring out what you can figure out. Figure out what you can't figure out. Use whatever resources (people, code, whatever) are available to you, and make the best decision for your company. It's not letting roadblocks get in the way. And if, after every avenue has been explored and there still is not an answer, then having the experience to produce an actual report demonstrating the code is too complex to reasonably make the required changes, present it to executives, and expect to be taken seriously. It will contain details of your investigations and alternatives to explore.

Autonomous here means you're not dead when something seems intractable. You keep pushing.

There’s usually a “ramp up” period where you get to learn that knowledge. As you get more senior, that period gets longer.

You also have to develop your learning skills. How do you identify existing people with knowledge and be able to learn from them.

Reply on news.ycombinator.com