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!

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.

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 &lt;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 &amp; 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 &amp; 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 &amp; recruiter to align communication, but given that I already said I’m leaving that can only be damage control.

So my company has a budget of around 200$ which would expire by the year end if I don't spend it on courses, books, trainings, etc.

I'm interested in knowing what you'd do or suggest. I'm in a full stack role and have tried the below.

1. Pluralsight has good material for many topics but they're outdated many times, especially for cloud topics.
2. Udemy has mostly up to date content and many really good creators but lacks coverage of advanced topics like pluralsight.
3. Coursera has good University courses but make little sense in real life development.

What are some of the ways you'd have spent this budget? What are some other sites worth looking into?

What's something you've gotten into your CICD pipeline recently that you like?

I recently automated a little bot for our GitHub CICD. It runs a few tests that we care about, but don't want to block deployment, and posts them on the PR. It uses gh pr comment --edit-last so it isn't spammint the channel. It's been pretty helpful in automating some of the more annoying parts of code review.

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

> I have spent some time trying to simplify the release process. For a variety of reasons, we can only release on Thursdays. The code is "frozen" on Tuesday before it can be released on Thursday. But we sometimes squeeze in a quick fix on Wednesday as well. > > The question, is when should QA test the code? > > Here is what I have seen happen: > > 1. Dev writes code and sends it to QA. > 2. QA finds problems, sends it back to the Dev. > 3. Dev fixes and sends it back to QA. > > I have seen a Dev fix their code on Tuesday, and then QA comes back on Wednesday with problems, when the code should have been frozen anyway. > > I am looking, what should be the best solution here. > > We have several problems going on at once: > > 1. Developers test on the same server as QA tests. I am working to switch developers to a separate Dev server, but it is a long work in progress. > 2. We don't have an easy way to revert code back from the QA server. It is easier to build revisions than revert changes. We can try to revert code more, but it will require a culture change. > 3. QA don't really have a schedule when they are supposed to do functional testing vs regression testing. > > I don't know what is the best way to proceed forward. Thus far, I haven't thought too much about the QA because I was focused more on getting releases out. Now that releasing is more simplified, that we can potentially do weekly releases, I am trying to see how we should proceed with the testing process.

In my short career I've noticed that employers are notorious for underpaying you to the point that people with 3-4 years of experience are getting paid the same as freshers. The management always has an excuse to not increase pay or increase it very minimally. The best way to increase pay has been to keep moving every 2-3 years from one company to the next if switching means at least 1.5x or 2x the current salary.

This means major interview prep requiring solving leetcode style questions, solving system design questions, then some more. I just wanted to how often do you prepare? Are you always interview ready or start prepping a few months before switching jobs?

Developers are operating and building in more and more heterogeneous and complex systems. This article offers some thoughts on how to think about "developer experience" in this world that's increasingly more like a "rainforest" than a "well tended garden".

I'm wondering if there is a new tool out there that I'm missing out on.

I wanted to ask a technical questions, maybe high level, on why sites may have bad search and what the bottlenecks might be in almost never updating such in years. Was there something in the original development of the stack that is affecting progressive updates around the feature, how should one approach "Search" then in this case? Or is it simply a management issue.

I have been working in the industry for 8 years and am now considered a senior developer, also as a team lead.

Three years ago, my first child was born, and a few months ago, a second one arrived. While I don't regret my decision to have kids at all, I do feel bad about how the lack of free time affects my career and how my knowledge falls behind the industry.

Before having kids, I used to spend a few hours a week on never-ending personal projects to learn new things. However, now I neither have the time nor the energy for that.

The only way that has worked for me is to read some tech books, which are often not about coding, and to read some blogs or subs like this.

However, I feel like this approach is too passive and is not providing the best outcome that I would expect.

Any tips there, perhaps from someone who was is similar situation?

I was wondering if anyone else had any questions they always asked the interviewer in the "we'll give you five minutes at the end to ask us questions" bit in interviews.

Personally I always ask what the staff turnover rate is. Mainly because in my first dev job I was one of four people who started on the same day. One of the other guys left after two days, I left after six weeks, and another guy left after two months.

Another I'll be asking after my current job is if they have a mainframe. I've now worked at three companies with mainframes and they all were old corporations where they were outsourcing loads of stuff to unhelpful companies (often IBM) which generally meant lots of headaches.

I've thought it over, and I've decided the best next step for me is to shift from a software developer to a management role.

I've worked a lot of high stress, fast paced positions, mostly in R&D groups/companies, which I always excelled at. I now understand why I did well in that type of environment (undiagnosed ADHD), and how to be properly organized enough to perform in an SDM role (ADHD meds lol).

Honestly sitting in meetings for 30+ hours a week doesn't sound so bad anymore. Racing to get a lot of technical work done in a tight timeline now sounds miserable. I've had some amazing SDMs, and I'm confident I can be better at it than most I've worked under.

So: any and all thoughts, what books or resources would you have recommended to yourself, what companies or roles might be a particularly good fit.

Hiya

If you're at all like me, there's the manic periods of development, where things get done... and there are the lulls. What do you like to do in those lulls? Do you have a bin of fun work shit to do? Do you watch videos? Touch grass? Socialize?

Just curious

Now have direct reports under me. No idea wtf I'm doing, I guess I did a good job? Any advice you have for me?

I wonder if there are others using ADRs for documenting their decisions.

I have been working at a large bank for a few years. Although some coding is needed, the bulk majority of time is spent on server config changes, releasing code to production, asking other people for approvals, auth roles, and of course tons of meetings with the end user to find out what they need.

I guess when I was a junior engineer, I would spend more time looking at code, though I used to work for small companies. So it is hard for me to judge if the extra time spent coding, was because of me being a junior or because it was a small company.

The kicker, is when we interview devs, most of the interview is just about coding. Very little of it is about the stuff I listed..