understanding a big codebase you have never worked.

Somewhere between API resources, queue workers, repositories, clients and serializers there is a class of ... classes/modules that does the needful. Gun-to-my-head, I would call them "services" but I'm looking for a less overloaded term. Maybe capabilities? Controllers? Pick a term from the business domain? What do you call them?

I want to document my debugging sessions in a text file but I don't know if anyone did this before.

I came up with this kind of "language" that is a mix between Markdown and C++, but I still wonder if something equivalent exists already.

// When you click on the button
# [click button]
- A::f()
// - ... other method calls, don't document if you don't need to

# A::f()
// "..." for "parameters" where you don't need the details
- Stuff::g(...)
- Stuff::h(...)

// <Class> is a fake template thing to show the possible types of an object
# <SubStuffA | SubStuffB> Stuff::g(...)
- Stuff::g() {} // empty but I use v/=> for virtual call
  v/=> SubStuffA::g()
  v/=> SubStuffB::g()

# SubStuffA::g()

# SubStuffB::g()

# Stuff::h(...)

I document methods in the order of appearance in the code.

If you have any good idea about a reliable way to document a list of function calls, I'm interested!

cross-posted from: https://programming.dev/post/9846214

cross-posted from: https://programming.dev/post/9846201

Project CRaC, Correlation IDs, SSL Bundle Reloading and more.

I noticed that some of the mods here are also the mods of r/experienceddevs. That subreddit is quite active. Perhaps it would be effective to have automoderator throw a sticky on every post there, just saying welcome to r/ExperiencedDevs, please follow the rules, etc and at the bottom: Did you know we have a Lemmy community? With a link here.

Last year, the company I work for was looking to hire a Senior Backend Engineer. Above all, we wanted our interview to favor candidates that are good fits. Now, after working with our new hire for about 11 months, we know that we succeeded. This is how we went about designing the interview.

cross-posted from: https://programming.dev/post/6236976

In this article, we’ll debunk the notion that Java is a relic of the past and showcase the language’s modern features, thriving ecosystem, and unwavering presence in enterprise and open-source communities.

I am a self-taught programmer and I do not have imposter syndrome. I have a degree in electrical engineering and when I thought that was going to be my career I did have imposter syndrome, so I'm not immune. I wonder if there's a correlation. It seems that many if not most professionals suffer from imposter syndrome; I wonder if that's related to the way they learned.

When I say self-taught, I don't mean I never took a class, I mean the majority of my programming skill was learned by doing/outside of classes. I took a Java class in high school that helped me graduate from procedural languages to OOP, and I took classes in college but with few exceptions the ones that were practical (vs theoretical) covered material I already knew.

My last job was at a company that designed and built satellites to order. There was a well defined process for this, and systems engineers were a big part of it. Maybe my experience there is distorting my perspective, but it seems to me that any sufficiently complex project needs to include systems engineering, even if the person doing that is not called a systems engineer. Yet as far as I can tell, it isn't really a thing in the software industry. When I look at job postings and "about us" blog posts about how a company operates, I don't see systems engineering mentioned. Am I just not seeing it, is it called something else, or is the majority of the industry somehow operating without it?

I'm working on a website that can be best described as "OkCupid crossed with LinkedIn". It aims to help employers and potential employees to figure out if there is a good fit between professionals (whether they are looking for a job or not) and their positions within the team.

Like OkCupid, the idea is to have a catalog of questions in different topics, and everyone can say what they would like to "hear" from a good match. Questions range from interest in company practices (remote vs office-based? what do you think of pair programming?) to preferred management approaches (Do you like to work within a Scrum setting? What is your approach for Buy vs build? ) to opinions about technology stacks and even general cultural values (Do you contribute to open source? Do you think it's important to have side-projects?). As more people answer more questions, it will be able to have a "affinity score" between people and if nothing else it could work as an ice-breaker during an actual interview with a candidate.

If anyone here would like to take go through the questions and help me come up with more ideas.

Assuming you have one at all, what time do you have your daily stand up meeting? Are there reasons why you have it at that time? Do you like having it at that time?

I'm new to this weekly syncup thing with my manager and he already knows the things I work on through daily standups, the issues I've faced or things that have gone great through retros after every sprint.

This gives me little to talk about with my manager except personal goals sometimes, a bit about our lives in general, etc. I was wondering what you guys discuss and how do you make best use of this meeting?

I got a reply from a recruiter to setup a call later this week. I know one of the inevitable questions will be why am I looking to leave my current role.

Personally I want to leave because:

• I have a junior role in the company and I don't see a way of reaching a mid level here.
• The targets for promotion are constantly moving. The managers have changed a few times over the past 4 years and so have the appraisal systems.
• I haven't been given any real projects since the last manager has started. Mainly whack-a-mole type security tasks. This is especially frustrating as I have worked on larger projects before then.
• lots of senior engineers have joined, introduced a new product/application, and then left.
• which leads to lots of firefighting and understanding how things were implemented due to the seniors poor documentation.
• so I'm learning nothing on the job and I'm not working on anything special to talk about.

So would something like 'looking for new opportunities' be sufficient?

Ps. If you got this far, thanks for reading my rant. It has been locked away in my head for some time now.

this collection of thoughts on software development gathered by grug brain developer

grug brain developer not so smart, but grug brain developer program many long year and learn some things although mostly still confused

grug brain developer try collect learns into small, easily digestible and funny page, not only for you, the young grug, but also for him because as grug brain developer get older he forget important things, like what had for breakfast or if put pants on

End to end and smoke tests give a really valuable angle on what the app is doing and can warn you about failures before they happen. However, because they're working with a live app and a live database over a live network, they can introduce a lot of flakiness. Beyond just changes to the app, different data in the environment or other issues can cause a smoke test failure.

How do you handle the inherent flakiness of testing against a live app?

When do you run smokes? On every phoenix branch? Pre-prod? Prod only?

Who fixes the issues that the smokes find?

I looked for Senior Software Developer positions, and one of the things that I've noticed is that lots of enterprises look for people with experience with technologies such as .NET and C#.

I personally HATE Microsoft and their platforms. From my experience they take all the fun from developing by creating stupid compile errors with their stupid gigantic Visual Studio and buggy dependencies. Not to mention their ridiculous resources greedy and unsecured Windows OS! Also there are no healthy and independent communities around a their technologies. They don't open source much of their technologies so it would be easier to hack their tools, and harder to make security patches.

Why enterprises do that for themselves and for their developers?

Do you think enterprises will make a turn in this attitude?

More specifically, I'm thinking about two different modes of development for a library (private to the company) that's already relied upon by other libraries and applications:

1. Rapidly develop the library "in isolation" without being slowed down by keeping all of the users in sync. This causes more divergence and merge effort the longer you wait to upgrade users.
2. Make all changes in lock-step with users, keeping everyone in sync for every change that is made. This will be slower and might result in wasted work if experimental changes are not successful.

As a side note: I believe these approaches are similar in spirit to the continuum of microservices vs monoliths.

Speaking from recent experience, I feel like I'm repeatedly finding that users of my library have built towers upon obsolete APIs, because there have been multiple phases of experimentation that necessitated large changes. So with each change, large amounts of code need to be rewritten.

I still think that approach #1 was justified during the early stages of the project, since I wanted to identify all of the design problems as quickly as possible through iteration. But as the API is getting closer to stabilization, I think I need to switch to mode #2.

How do you know when is the right time to switch? Are there any good strategies for avoiding painful upgrades?

Any recommendations?

What is your opinion about full-stack teams? I'm referring to teams where the desire is for every member to competently contribute at every point in the stack.

• Do they work?
• What has been your experience?
• Does team size and/or experience level inform your opinion?
• Do you notice an increase/decrease in quality?
• Do you notice an increase/decrease in team and product cohesion?

Domain-driven design includes the idea of a "ubiquitous language" where the engineers and the domain experts and the product owners come together and agree on terminology for all the domain concepts, and the project then uses that terminology everywhere.

But on the projects I've been involved with, much more common is a situation where the requirements docs mostly use one term but sometimes use a different name for the same thing because the docs were worked on by two people who disagreed on the terms, the designers decide they don't like how the words look so the UI calls the concept something else, the database developer reverses the term's word order to fit their personally-preferred schema naming conventions, the API designer invents a compound name that includes both the UI and the database names, and so on. (I only barely exaggerate.) Which names map to which other names becomes tribal knowledge that's usually not written down anywhere.

This kind of thing bugs me a lot, but I seem to be in the minority. I recognize that it makes very little functional difference, but it just feels sloppy to me and I don't like having to remember multiple names for things. I will usually advocate for renaming things in the code for consistency, and other people on the team will almost always agree that it's a good idea and will happily accept my PRs, but I'm usually the only one taking the initiative.

So, my question to you fine folks: am I wrong to care much about this? Do you think using consistent names for domain concepts across the board actually makes a meaningful difference in terms of code maintainability and discoverability? Or is the effort required to keep the names consistent over time actually greater than the mental overhead of working with the inconsistent names?

.yaml, .toml, etc?

I'm like a test unitarian. Unit tests? Great. Integration tests? Awesome. End to end tests? If you're into that kind of thing, go for it. Coverage of lines of code doesn't matter. Coverage of critical business functions does. I think TDD can be a cult, but writing software that way for a little bit is a good training exercise.

I'm a senior engineer at a small startup. We need to move fast, ship new stuff fast, and get things moving. We've got CICD running mocked unit tests, integration tests, and end to end tests, with patterns and tooling for each.

I have support from the CTO in getting more testing in, and I'm able to use testing to cover bugs and regressions, and there's solid testing on a few critical user path features. However, I get resistance from the team on getting enough testing to prevent regressions going forward.

The resistance is usually along lines like:

• You shouldn't have to refactor to test something
• We shouldn't use mocks, only integration testing works.
  • Repeat for test types N and M
• We can't test yet, we're going to make changes soon.

How can I convince the team that the tools available to them will help, and will improve their productivity and cut down time having to firefight?

Hey! So to make a long story short, about 2 months ago I learned that I’ll probably be PIP’ed (posted about this here btw and received super helpful advice, thanks <3). I thought this comes only from my direct manager (who is leaving now), but after talking to my skip level they seemed to support the decision. 
After learning this I immediately started reaching out to other teams who were hiring, because I’m in a big tech company and an external switch is complicated in the current market.

Fast forward, a manager from another team wanted to hire me. I didn’t want to raise any attention until I had a confirmation that this is a done deal. Hiring manager + recruiter told me they want to hire me, so I had to talk to my skip level & manager. I was really afraid of doing this too early because of how bad it looks if it doesn't work out, but at this point I had no choice.

I phrased the conversations with my managers as asking for advice if it makes sense or not. Skip level told me immediately it’s a great idea and I should go for it, manager was more neutral, but there were no efforts made to retain me.

Last week, I told them that I’d decide to go for it, so my managers and the hiring managers had a conversation.

In the meantime, I did my job as usual and didn’t inform anyone else. This week I learned as expected that I’d be pip’ed in my current role if I stayed, so leaving would have been a good choice. However according to management the PIP isn't designed to force me out but "to help me improve" (not very conifdent that they really mean it though).

This week, I also got informed though that eventually the other team moved forward with another candidate. Fair enough, no hard feelings, but why do you make me go to my managers if the decision isn’t final?

The reasons were:

1. Concerns regarding remote work
2. Technical skills

My company has RTO going on and I’m currently remote, apparently the new director is a fan of coming to the office.

Anyway, I’m applying externally, and I have some processes going on, but nothing concrete, so it seems like I’m forced to stay in my current role. I’d be okay with being laid off, but I can’t quit myself because I’d lose on a lot of benefits (not in the US) and also severance.

My idea was that I would need to say that eventually I backed off due to not being able to agree on some issues revolving around workmode and start date.

Afterwards I would then ask to sit down with manager & skip level and address the points that make me unhappy and ask for a clear trajectory from their side to address these and also on how they imagine collaborating given the PIP they triggered.

Does that seem to make sense to you? I mean if I can leave I will leave immediately, but currently that's not an option yet.

So now I’m really wondering how to go from here? I’m currently aligning with the hiring manager & recruiter to align communication, but given that I already said I’m leaving that can only be damage control.