Experienced Devs

As a senior developer, I don't find copilot particularly useful. Maybe it would have been more useful earlier in my career, but at this point writing a prompt to get copilot to regurgitate useful code and massaging the resulting output almost always takes as much or more time as it would for me just to write whatever it is I need to write. If I am able to give copilot a sufficiently specific prompt that it can 'solve' my problem for me, I already know how to solve the problem and how to write the code. So all I'm doing is using copilot as a ghost writer instead of writing it myself. And it doesn't seem to be any faster. The autocomplete features are net helpful because they're actually what I want often enough to offset the cost of reading the suggestion and deciding if it's useful. But it's not a huge difference (vs writing it myself) so that by itself is not sufficiently useful to justify paying the cost myself nor sufficient motivation to go to the effort of convincing my employer to pay for it.

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?