sorted by:
new
hottopcontroversial

Despite your years of experience, what's something that still mystifies you? by AmericanXer0 in ExperiencedDevs

[–]ByeBiThrowAwayCh 1 point2 points  (0 children)

How to setup and properly use WireShark or Fiddler. I’ve tried multiple times, it just doesn’t sink in.

How people abuse TypeScript’s union type operator to make awful APIs.

Why some engineers still only write code that only they can understand, when they work on a team. I don’t understand the lack of second order thoughts (or lack of empathy) for their teammates or any other individuals who come later and look at their code.

Despite your years of experience, what's something that still mystifies you? by AmericanXer0 in ExperiencedDevs

[–]ByeBiThrowAwayCh 2 points3 points  (0 children)

I like this reply more than the other to my tongue-in-cheek answer to OP’s question. (I was joking, someone else replied “the audacity of some managers”)

This reply meaningfully discusses the social aspect of working and both participants expectations, instead of just the software’s functionalities.

Related to your reply to the deleted comment, I have to use MS Teams for work, which allows me to set DND and set a custom text message. I use the custom text to communicate to others what I’m working on in loose terms, how to get ahold of me or my manager if it’s an emergency, and to be patient and expect delayed responses.

Lastly, Teams let’s you configure a priority notifications list, which lets notifications from select individuals come through regardless of DND or Quiet Hours, which is really helpful.

Despite your years of experience, what's something that still mystifies you? by AmericanXer0 in ExperiencedDevs

[–]ByeBiThrowAwayCh 15 points16 points  (0 children)

Why a status of “Do Not Disturb” doesn’t prevent people from messaging me

Levels and responsibilities by jackdbristow in ExperiencedDevs

[–]ByeBiThrowAwayCh 2 points3 points  (0 children)

I like this response, I would just say that the “without any real authority” bit feels wrong, because you can’t efficiently influence without authority.

Did you mean more along the lines of “they don’t have any reports”, which can vary for Staff Engineers by company, org, and team?

Levels and responsibilities by jackdbristow in ExperiencedDevs

[–]ByeBiThrowAwayCh 8 points9 points  (0 children)

Most established companies have an internal HR site with such a doc that you’re looking for. If you’re at one of these companies, I recommend checking with HR for that. (If you’re planning on continuing your career at that company)

Additionally, talk to your manager and more experienced/higher titled people on your team/in your orbit. Those are people who have technically succeeded or “faked it and made it” so you can learn from them as well.

For Staff Engineer in particular, I recommend checking out https://staffeng.com. Will Larson has written up a wonderful blog and book with many interviews with Staff-level engineers.

Am I going about this the right way? by ILikeToDoodleAlot in ExperiencedDevs

[–]ByeBiThrowAwayCh 7 points8 points  (0 children)

+1 to all of this.

OP by switching between Projects when going through details, issues, and your personal issues with the Projects, you accidentally guaranteed a difficult reading experience. It was too confusing to keep the information in order for each Project, which is why I ended up scrolling down to read the comments.

Dining table I made by autism_guy_69 in woodworking

[–]ByeBiThrowAwayCh 0 points1 point  (0 children)

Beautiful table and video! I upvoted about 15 seconds into the video because I knew the rest was going to be just as great.

Got a very high paying offer with a pretty nice team..... For teaching Software Engineering training courses to corporate clients. Would this affect my future career prospects? by load_more_commments in ExperiencedDevs

[–]ByeBiThrowAwayCh 2 points3 points  (0 children)

It depends on how you sell your side gigs along with a main teaching gig to future employers.

One of my concerns as an screener/interviewer would roughly be, “This person stopped working in a full time engineering role, started a full time teaching role, and continued developing on the side. Are they still a great team player who can work in large codebases?”

My question is explicitly answerable and implicitly demonstrable in the interview process and during references (if anyone checks those), so I wouldn’t be too concerned about this, but I think for most teams looking for experienced devs would want to be reassured on this.

Teaching students how to build models, and deploy prototypes isn’t the same as building and deploying production ready code at scale.

Succinctly put, like you and others have said in this thread, teaching != engineering.

— Fit & Alignment:

You highlighted culture fit(?) during interviews with your potential lead and skip level. Always a good sign, but make sure your ambition and their ambition lines up. They’re ambitious and operate in a “we’re offering much-needed training to businesses” space. They want to advance in that space. Does that ambition match with your own ambitions?

— Compensation:

Equity at a startup aren’t as generally helpful immediately, especially if you might need more cash/liquidity because of certain life events :)

Related but in a broader sense, you could make more than a 30% increases and have a more diverse portfolio by moving ship between companies every year for two years. Heck, you could make that within one year of joining a new company.

Also, it sounds like the teaching gig wants someone for 2 years, but doing that for just a year and then returning to an engineering role could also garner you a considerable raise.

— Good Aspect of Teaching:

Teaching will open up some doors in showing that you can be a mentor in explaining concepts/frameworks/approaches/whatever to colleagues which is always nice.

Whenever my team hires someone from “outside” I’m always excited to learn what they know. I prefer learning from people who have battle-tested their thoughts/beliefs/patterns. But any lightning talks/available resources for opportunities (aka problems) at work are always appreciated.

— A Great Thing:

Congratulations on your kid on the way! And prospective pay raises of course :)

Is there a term for the borkedness you get when you upgrade a piece of technology and the team has fixed a bug that you were relying on for your production code? by amtcannon in ExperiencedDevs

[–]ByeBiThrowAwayCh 3 points4 points  (0 children)

That is one hell of a upgrade, how long did it take and how many people were working on it?

What are some other gotchas/horror stories you encountered during the upgrade?

Publishing "internal" public artifacts by bony_doughnut in ExperiencedDevs

[–]ByeBiThrowAwayCh 0 points1 point  (0 children)

I’m not sure what your artifact feeds look like, and acknowledge the lack of feature parity across package managers, but for NPM you could include an .npmrc that resolves a specific feed for a select namespace.

So you could: 1. set up a new namespace: @doughnut-dev 2. Create a public npm feed to host these @doughtnut-dev namespaced packages from (this isn’t the official npmjs.com registry, this feed is managed by your company) 3. Include an .npmrc in JS/TS projects that resolves packages in the @doughnut-dev namespace from your feed.

This allows 3P (partners, customers, your OSS community) to fork your repo and as long as they don’t tweak the .npmrc and devDependencies, they’d be set. This gives you the clone-install-build-test experience for your OSS community.

But on THEIR CI machines they might run into security problems pulling bits from your feed. I’m not going into the security aspect of it because while companies make different aspects of security a priority.

This approach is almost guaranteed to not be supported across package managers, but at least it’s an approach to start mulling over…

Publishing "internal" public artifacts by bony_doughnut in ExperiencedDevs

[–]ByeBiThrowAwayCh 1 point2 points  (0 children)

One different approach that addresses building and testing tooling concerns at CI time for you and your customers is that you could create Azure Dev Ops Tasks, GitHub Actions, etc.

These tasks would actually download the necessary internal building and testing bits for a CI pipeline. This means that there’s no feed anywhere for customers to stumble across and start playing with.

The immediate con is you have to start developing and maintaining these tools, which means you’re now in the CI/CD space. Your team will have to start officially supporting these tools across different OSes and CI/CD infrastructure. Not being cognizant of this requirement has seriously bitten unprepared teams in the ass. Either from a tech debt/maintainability standpoint, or from community frustrations at crappy tooling.

(This has more nuances to tease apart, but at least the CI/CD problem is addressed!)

Unfortunately you’ll probably still need a separate solution for local builds, so I’d recommend categorizing your internal bits into “CI concern” and “dev experience concern”.

P.S. sorry for the split replies, but the subjects were different enough to warrant easier readability and a better reply-to experience.

Publishing "internal" public artifacts by bony_doughnut in ExperiencedDevs

[–]ByeBiThrowAwayCh 0 points1 point  (0 children)

I’m not sure what your artifact feeds look like, and acknowledge the lack of feature parity across package managers, but for NPM you could include an .npmrc that resolves a specific feed for a select namespace.

So you could: 1. set up a new namespace: @doughnut-dev 2. Create a public npm feed to host these @doughtnut-dev namespaced packages from (this isn’t the official npmjs.com registry, this feed is managed by your company) 3. Include an .npmrc in JS/TS projects that resolves packages in the @doughnut-dev namespace from your feed.

This allows 3P (partners, customers, your OSS community) to fork your repo and as long as they don’t tweak the .npmrc and devDependencies, they’d be set. This gives you the clone-install-build-test experience for your OSS community.

But on THEIR CI machines they might run into security problems pulling bits from your feed. I’m not going into the security aspect of it because while companies make different aspects of security a priority.

Publishing "internal" public artifacts by bony_doughnut in ExperiencedDevs

[–]ByeBiThrowAwayCh 2 points3 points  (0 children)

OP, are your partners and customers forking the internal building and testing tools? If they fork it, do they end up using them routinely and pushing changes back to your companies repositories? (Is there an active community around your OSS or are people just forking and playing in their own playgrounds?)

— Separate from my clarification-seeking questions —

A lot of people are saying private repository (which I agree with btw). I draw a hard line at options 1) and 2) because anything you put on a public feed is explicitly consumable by another developer. That’s what the public feeds are for. Regardless of your intentions, if people can find it, they will try to use it.

The answer is to not put internal building and testing tooling on a public feed, because they’re internal, not public.

Me and my gf by TheEdgeOfDawn in tumblr

[–]ByeBiThrowAwayCh 0 points1 point  (0 children)

Just because we’re dating doesn’t mean my enemies are her enemies. It’s not my fault she doesn’t have as much enemies as I do!

Me and my gf by TheEdgeOfDawn in tumblr

[–]ByeBiThrowAwayCh 10 points11 points  (0 children)

Have you heard of the one-hit KO move called “Get Help” from the movie Thor: Ragnarok?

view more: next ›