Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Absolute truths I unlearned as junior developer (2019)

monicalent.com

Post reply on HN
Print view View original

251–260 of 269 posts

Re: Absolute truths I unlearned as junior developer (2019)

#251

Post by urthor »

marcosdumay wrote: post #200
ozim wrote: post #140

Earlier quoted context omitted.

Sadly it is a smart thing. But not only to get any code to prod. From my perspective it is to stop loads of stupid code/stupid solutions even way before it is written down as a task on your favorite task tracking tool. That is what meetings are for as well.

You seem to be arguing into promoting seniors into architects. The GP is arguing into promoting them to management. If the one hard problem your place has is organizing all the easy problems so they add to each other, turning your seniors into architects makes a lot of sense. And that's a very common situation. But the GP's motivation for moving them into management is basically that the organization is dysfunctional…

Management and architecture roles are essentially interchangeable.

"People who go to meetings and don't directly contribute to the product." Aka communication overhead.

I don't think it's about job titles.

It's simply that, senior engineers who COULD do direct work on the product, instead devote time to communication overhead.

Re: Absolute truths I unlearned as junior developer (2019)

#252

Post by urthor »

ozim wrote: post #209
marcosdumay wrote: post #200

Earlier quoted context omitted.

You seem to be arguing into promoting seniors into architects. The GP is arguing into promoting them to management. If the one hard problem your place has is organizing all the easy problems so they add to each other, turning your seniors into architects makes a lot of sense. And that's a very common situation. But the GP's motivation for moving them into management is basically that the organization is dysfunctional…

I am mostly thinking about technical team lead role which is not an architect and not managerial role. Team lead does not have time to code most of the time but does code reviews and attends meetings with architects and others and works on aligning stars so things happen. Then also has to stop stupid ideas or propose how to better solve a problem for a customer. But as I read GP post again it seems he might mean actu…

I'm unfamiliar with the term GP.

However, what you've said is exactly right.

A tech lead codes less, but they directly contribute to producing the engineering artifact.

They are an "actual contributor with direct responsibility."

However, all meetings that the tech lead has with people OUTSIDE the team, is communication overhead to be minimized. So a tech lead combines code review, external communication, and direct work on the engineering artifact.

Communication overhead is the problem. Architects, people managers, are all overhead roles. They don't "actually contribute" to the product.

The more strictly define it, it's not actually about the "fulltime role." Maybe the senior engineer doesn't change their job title, but their schedule becomes less about coding, more about communicating.

It's about minimizing the amount of external communication that needs to take place per code deployment.

Re: Absolute truths I unlearned as junior developer (2019)

#253

Post by phibz »

I see people get tech debt wrong. I've heard it called sorts of things. My current team thinks it's easy tasks, 1 pointers. I've seen it called sysadmin work that isn't business focused.

In my opinion tech debt is the result of a choice. Tech debt is the remainder of a solution modulo good enough. You choose to do something you consider less than perfect with the understanding that you're just delaying some of the work until later. That left over work is Tech debt.

For example, we need to implement auth on our web app, but let's hard code the permissions and do RBAC later. That's hard and not really valuable with such a limited feature set. RBAC in your web app is therefore Tech debt.

Re: Absolute truths I unlearned as junior developer (2019)

#254

Post by phibz »

icedchai wrote: post #245
kqr wrote: post #194

Earlier quoted context omitted.

I remember reading about an actual observational study on this -- I think on HBR -- and the conclusion was basically that managers that are technically skilled have much happier employees on average. Another finding from the same study was that the statements "I feel like my manager can do my job" and "I am not looking for new work" were strongly correlated. (This sounds like the same thing but isn't.) In other words…

I think either end of the spectrum is fine: highly skilled / can do your job if needed, or not technically skilled at all / honest about it / tracks schedule / delegates all technical authority. The messy middle is where the problems happen.

You can't be a coach and a player. It doesn't work. Having technical skills and being able to make or weigh in on big picture decisions is great. But you have to trust your team to do their job, even if it isn't exactly how you would do it. Does it meet the business need? Does it make sense strategically. Is your team staying unblocked? Are you being reactive or proactive? Are your team members growing and improving?

Re: Absolute truths I unlearned as junior developer (2019)

#255

Post by phibz »

BlargMcLarg wrote: post #220
rocqua wrote: post #205

Earlier quoted context omitted.

Let me rephrase: If your communication is bad, then you will need more communication to get to shared understanding. Yes, better communication would also be a great solution. But "if you are bad at X, just do X better" is meaningless advice. Useful advice is either how to fix the problem (advice on how to do X better) or less popularly but often very useful, how to mitigate the problem (advice on how to avoid bad out…

>Turns out that more communication is essentially the only way to mitigate ineffective communication. No, it's not. This is the equivalent of saying "if your writing sucks, just use more words". Anyone reading an overly terse, jumbled mess can tell you that's not the silver bullet. Somehow, that is the solution we go for whenever management is involved, until they figure out "oh crap maybe boggling our ICs with burea…

I agree quantity isn't the solution if communication quality is poor.

Communication is more than just talking at people. It's about having healthy boundaries, positive conflict resolution styles, being able to reach a decision quickly and explain it clearly and concisely to others. It'd about anticipating blockers and clearing them, streamlining process to keep things moving, being accountable and presenting security in yourself and your actions even if you might doubt them. But most of all its about listening and letting the team do their jobs.

Re: Absolute truths I unlearned as junior developer (2019)

#256

Post by lifeisstillgood »

jacobolus wrote: post #75
lifeisstillgood wrote: post #45

Earlier quoted context omitted.

Thank you. Agreed completely I see software as a form of literacy, and it both amuses and saddens me to hear things like "I used to write code, but since I moved to management I have stopped" We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" It seems sad to note that this "move to management" is now also becoming the "move to senior engineering". This indica…

> We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped" You surely would hear things like “I used to write research papers but since I moved to management I have stopped” or “I used to write fiction stories but since I moved to management I have stopped” or “I used to write legal briefs but since I moved to management I have stopped” etc. if you talked to people…

"I used to write fiction stories.." yes but they have not stopped reading and writing english on the job. In fact I bet that reading and writing english is still the job.

Things I think software management should be doing

(besides fighting politics that again should not exist but does because corruption)

- review of reviews (how is the code review process going, i'm on problems, common wins)

- code analysis - hot spots, changing idioms,

- keeping up with rest if company - what code issues / infrastructure / operational / metrics are coming, how do we adjust

Re: Absolute truths I unlearned as junior developer (2019)

#257

Post by mytailorisrich »

icedchai wrote: post #246
wokwokwok wrote: post #179

Earlier quoted context omitted.

> "Senior engineer/dev" is a title, this is not the same as being the 'senior member' of the team. I call bs. I should probably say, “that hasn’t been my experience”, but I just flat out don’t believe you. So, let me get this straight. In 20 years, you’ve found that senior developer is the role given to developers who have no responsibility above what a junior developer has, they just cost more? Rubbish. It’s a slidi…

In my experience, you are correct. In the wrong organization, you are eventually given so many "other" responsibilities, that you barely get to do any hands-on development work. You'll be doing code reviews, support, and documentation all day.

This is all part of "development work" and not tasks that mean you're 'senior'...

Re: Absolute truths I unlearned as junior developer (2019)

#258

Post by sally_glance »

kqr wrote: post #131
sally_glance wrote: post #79

Earlier quoted context omitted.

This reminds me of a very interesting comment on the engineering and management practices at Intel [1]: "I often called Intel an 'ant hill', because the engineers would swarm a project just like ants do a meal." I've seen it happen at smaller scales, great engineers in flat hierarchies without direction might not be the best idea from a business perspective... [1] https://news.ycombinator.com/item?id=31571560

Who says they have to be "without direction?" Only in a very hierarchical organisation are the lowest levels without direction -- because the higher levels maintain their position by keeping important information secret. If the important information (market signals, experiment outcomes, financial data, etc.) is made available to everyone, and everyone receives a sliver of training in interpreting it, any group of eng…

I like the idea, and I've seen it work for teams focusing on a single project/product. What's unsolved for me is how to scale this.

Interpreting data takes time, figuring out a strategy that spans multiple projects and years takes time... not sure this is workable to do individually. I'm all for being transparent with goals, that would be a given for me in any kind of organization - hierarchical or not. But somebody needs to keep up with the ideas of the engineers, customer requests, business goals and changing markets to put everything into an actionable strategy. In bigger orgs this is an ongoing process and requires full-time dedication... It would be really hard (but very interesting) to come up with a process to 'crowd-source' those things from 100+ engineers, skipping the middle-management positions.

Re: Absolute truths I unlearned as junior developer (2019)

#260

Post by badsectoracula »

feoren wrote: post #195
badsectoracula wrote: post #161

Earlier quoted context omitted.

> I can almost guarantee you that any codebase with a "Player" class that looks anything like your example is a very poor codebase. It shows me they just didn't know where to start, so they started by throwing everything in there. And then there is Unreal Engine 5's ACharacter class[0] :-P. I recommend checking the superclasses too. [0] https://docs.unrealengine.com/5.0/en-US/API/Runtime/Engine/G...

First off, I'll say that popular frameworks optimize for being popular, which usually means they let inexperienced people make cool things quickly. This necessarily involves tradeoffs that end up being "walls" to more experienced coders. It's very very hard to let inexperienced people make cool things quickly without restricting power-coders. So "Unreal does it" doesn't necessarily mean it's the right choice for grea…

> So "Unreal does it" doesn't necessarily mean it's the right choice for great code [...] "But dude, YAGNI! Don't try to predict the future" you say, missing the point.

Actually i'd say the opposite, "Unreal does it" indeed doesn't mean it's the right choice, but that "Unreal does it" proves that in practice that stuff doesn't matter - Unreal is a codebase going back decades and yet it is as popular among developers as it ever was (some developers even throw away their own engines to switch to it).

So while these topics can be amusing to read, in reality they are bikeshedding of little more importance than using spaces vs tabs or where to put curly braces and how that affects diff tools.

Post reply on HN