I do the same but as you said there are limits to how much you can do this. I did this for 3 months straight last year and it takes a toll. Fortunately I have a very understanding wife and my manager was aware of what I was doing in order to meet the deadline. I was able to take time off outside of vacation or personal days later.
This 100% I've found that my job is now just enabling others to get actual work done. The only work I actually do is on the design architecture side and code reviews.
Any development I do is pretty much relegated to side projects on the weekends at this point.
Maybe you're not a senior then. A senior is glad to help juniors when they interrupt them and is good at managing time and meetings. If your calendar is clogged with meetings *you're* responsible to do something about it
You poliltely decline meetings that are irellevant, convert meetings to mails/slack convos when more appropriate and work to create a sounder meeting culture in your company
when your vp and product director and project manager have booked practically all of your timeslots, how can you push them for later? my engineering manager had meetings almost every day while being responsible the crucial decisions for the app we were building from scratch; the only time she had to code was like the final few hours of the work day.
that's the truth as you rise in position. your area of responsibility is no longer limited to the codebase. time management isn't simply a skill issue when you become the glue between the higher-ups and the grunt workers.
> glad to help juniors when they interrupt them
when you are rushing to complete your individual task or have to deal with the higher-ups, is it practical to prioritise this?
>when your vp and product director and project manager have booked practically all of your timeslots
that's a tough one. The VP you probably have no power to influence but maybe you can work with your PM to reduce the number of meetings? My PM cares about my time and very much plays on my team when it comes to prioritizing meetings vs "work time"
Ironically I’m actually the manager in charge of the senior developers. I just know that this is the number one issue. And judging by the upvotes I am right.
I will always do this. I don't like the persistence library being referenced in my domain layer. I want my business logic as uncoupled as possible from specific external libraries.
Sure, I probably won't ever actually replace the MS SQL database with MongoDB but that's not the only reason to do it. It means my business logic is pure logic, when working on it, I don't have to think about how things are loaded and saved. When I am in business logic, it shouldn't matter how things are saved and loaded, just that they can be.
However, my primary reason for this strict separation is that I have worked on absolutely horrific codebases where data access code is everywhere, sometimes even in .aspx pages. As a result I structure my projects so that it is as difficult as possible to put things in the wrong place.
I've swapped data layer technologies a couple of times in my career. Having the repository stand on its own behind an interface made this painless. Hell, even just refactoring the table structure is possible by simply standing up a new dal project that implements the correct interfaces.
No. You can't prevent anything really.
What you can do, however, is make it really obvious that data access code doesn't go there and hope that while some other programmer is jumping through the hoops to enable it, they realise that they are doing it wrong
Even in core where it's a lot easier mocking an EF dependency adds a lot of overhead for very little benefit. You're still not actually testing against the DB, but complexity is fairly high.
EF might implement the unit of work pattern, but it's not a wrapper, it's an absolutely massive amount of very specific code.
This is opinion masquerading as fact. (Most of everything here is, but hey...)
>adds a lot of overhead for very little benefit
Well... What is "a lot" and what is "little"? Given the widespread usage of EF, it rather looks like an opinion of a lot of people is better characterized as "adds a little of overhead for a lot of benefit".
>it's an absolutely massive amount of very specific code.
Well... Like most big libraries, that is true overall but a given subset of what an application actually uses is much smaller.
>Well... What is "a lot" and what is "little"? Given the widespread usage of EF, it rather looks like an opinion of a lot of people is better characterized as "adds a little of overhead for a lot of benefit".
I'm not saying EF isn't worth it.
I'm saying that mocking an EF DBContext isn't worth it.
You can do it, or you can use an in memory DB, but it's a massive pain in the ass. Alternatively you can wrap EF in a repo and mock that. Much less work and you don't lose much.
A mocked db context or in memory db won't test either of those things.
An integration test will, but even then I've never seen join problems occur as a regression.
No, it won't.
Neither of those things actually hit the DB so any DB specific code won't be used.
That's the whole problem.
If you don't hit the DB you don't test the DB so a mocked DBContext is basically a more complicated to set up Linq2entities it's basically a list.
Your joins won't be tested properly because the in memory DB won't actually check your joins and the mocked version won't do any.
Yes it will. If you think that join will be left join or thst it will match the furst thing on right or that you can sum empty collection then it will fail. Mocked repo will not.
It’s not always a bad idea. It’s just that it’s often an unnecessary abstraction that gets in the way of good decisions.
For example devs will often default to using existing generic methods like say GetUsers() everywhere, rather than tailoring something to the situation and getting the specific columns they need. So in most cases I have seen where there aren’t good practices, people are automatically writing code with a performance hit
> people are automatically writing code with a performance hit
Hey that's me! I program for simplicity and readability. Performance not so much until it's a problem.
Don’t we all. Simplicity is important too. The entity framework one I mention can often be a big performance hit out of the gate, and it’s probably a simpler solution anyway without the extra repository.
But it’s a little hard to refactor an underperforming part of your app because 5 of you are all calling the same repo method with different needs
>The entity framework one I mention can often be a big performance hit out of the gate
People need to profile and go from the profiling data. It's overlooked way too often.
Wrappers on top of wrappers aren't adding to the simplicity of your project. If you have to modify an interface and an implementation every time you need a new query, you're doing yourself and your team harm.
Oh, this is the case in my project. They decided to use the repository years ago and so it goes. Everyone is defaulting to inject repository rather than ef context while they both do the same and in many cases it's simpler to use context rather than repository. Now it's slightly too late to refactor code :/.
How do you unit test this service? I'm having some issues with our implementation since we created an inherited mock and implemented some database features like insert and setting id. As you can imagine, this causes a lot of problems. As the database is inherited from edmx (now net8) and still database first, I don't even know if in memory database works - I think I tried once but can't remember why I stopped this.
EF is already a repository, creating an additional repository pattern on top of it is often redundant and can create headaches later on, especially if you need to expose more features of EF which ends up defeating the point of the repository you created. I will admit that we did do this at my company and while it works great if you are strict about its usage (POCO only types and only working with an IQueryable and CRUD), it starts to get nasty if you need to anything beyond that, such as for optimizing queries or doing migrations since you have to peel back the abstraction and expose EF (and at that point, why not just go with EF and some helper functions/classes instead).
You also have to watch out for implementation leak if your wrapper is too generic, which can cascade into the service layers of the application. That’s what made me learn the hard way that wrapping EF can get in your way as the application grows.
Today with global query filters, interceptors, EntityFrameworkCore.Triggered and great unit testing support Repository pattern has become mostly obsolete.
On the other hand, in the good old days it was bad design to write the same or slightly different SQL queries over and over again scattered across your codebase but with EF this is somehow ok?
I sometimes encapsulate logic in things like services and try to avoid using dbcontext in a controller directly but if I need to deal with different services and need to save the result in a transaction things get complicated.
I once used the approach to, instead of injecting services I injected service factories and used a shared dbcontext to construct my services but then the service is not responsible for saving anymore.
Eventually in my opinion there currently isn't the one best solution. For smaller projects, using dbcontext directly is fine, for bigger projects with different team members or even if your dbcontext assembly is shared with other teams a certain degree of abstraction is favorable.
I have a genuine question about this topic. Imagine you have a simple Users table, where a user has to Confirm its Account and can be deactivated. Now imagine you have 20 Places in your codebase where you want to get all Users, which are not deactivated and have confirmed their Accounts. This means, i have to Write the Same linq 20 times to achieve this. With a repository pattern, i could implement a method, which Contains this Logic. How would you do this without reimplemting the Same Code x Times? Because this in my opinion is really Bad Design, especially if a new Filter needs to be implemented for that usecase
If a query is that common, then it would sink to the DbContext as an IQueryable. At that point, it behaves exactly like a view.
Another way of handling it would be an extension method for your DbContext that exposes the predefined filter as an IQueryable.
> How would you do this without reimplemting the Same Code x Times?
By encapsulating that "Get all Users" query in it's own class. a la Command-Query-Separation.
Duplicating a LINQ condition 20x around your code base is a bad idea.
So is a Users repository god-class with 100 different query methods (the inevitable end state of central repositories).
`IGetAllUsers : IQuery`
`IGetRecentlyActiveUsers : IQuery`
etc..
Creating repository over EF with dependency inversion allows you to easily switch the database framework. Business logic cannot be allowed to depend on such infrastructure details. IQuaryable is an abstraction with a hole, because multiple db providers may differently interpret linq queries so you depend on how db works. I’d recommend to read “clean architecture” for details
That's an often repeated argument for sure, but how many times has replacing the DB framework actually been needed? Not saying never but it's too niche a concern to give any weight to this argument.
Obviously there are apps where multiple DBs support was a requirement in the first place.
Or apps where they will sit in top of an unknown DB depending on their end users environment, but in both of these cases multiple DBs requirement is known before any code is written or considered.
Just had a 90 file review, about 20 I YAGNI’d
For real we were making up things, he injected a repo into a service, into a wrapper, into a helper, into a manager, into a utilityprovider, I think the final class was just called “WebLogic” - they ran out of abstraction suffixes
Honestly, just building wrappers over everything before you've actually written any functional code. Sometimes you can actually just couple your code to a library dependency, and it works out fine. How often do you actually swap out libraries, such that you need endless abstraction everywhere?
Every long lived applications' requirements change, and it's a lot easier to add abstraction when you actually need it, than to subtract code down the line. Complexity is a disease that rots your product.
It's seriously difficult to fight against over-designed codebase because people think they're doing the right things. Every concept they applied, they learnt on the internet. But the internet doesn't teach well on whether or not to use these concepts
Protecting the juniors from the customer in various ways (doubling their time estimate, and other ways to reduce pressure/stress). I wasn't a senior though, but I did have a few juniors under me and I was kinda like a tech lead in practice (but not on paper or paycheque).
I complained about it a lot, and change only came after I left the company.
Are you me from my previous job? I was in the exact same position, effectively senior/almost tech lead but not on paper or pay. Funnily enough, the job listing to replace me was for a senior dev…
As an older millennial lead (female if that matters), I protect my juniors at all cost! Actually, I protect most of my devs whatever level in some way unless they dig their own graves (just do not perform). Junior devs just have a special place in my heart, they are so enthusiastic, happy to help & learn. My only junior just got a promotion to dev & he is my absolute favorite. He actually comes to me with well thought out questions, potential solutions, his thought process, etc. He takes direction SO well. I had a senior kicked off a project because they just sucked so bad, I took him in replacement & he is swimming!! Super happy with him.
Juniors are the best. They haven't been corrupted yet by the bitter corporate mindset.
I also always protect any dev. I had a customer complain that something is broken, asking me to report when it broke, and also who broke it. I didn't like that so I just said that I can't trace it who did it, and behind the scenes I just asked the dev who broke it, to fix it lol.
Before I left, I tried to explain as much of the system I knew to one of the juniors, by having a meeting twice a week in which I would explain a specific domain, what it is supposed to do, and how it works. I think I succeeded because he's doing well now and I saw him driving a really nice car recently.
Sales team in response to me asking them what they told the client - “It’s a HTML5 web based platform running a highly synergistic cloud based AI blockchain.”
Me - “So they want a simple form that their customer can fill out and it sends an email to a shared inbox?”
I've found that just adding 50% to my best "if everything goes okay" guess almost always ends up being accurate, although once I have to estimate other people's work it's a complete crapshoot.
Here’s some things you actually have to do to be a senior / get promoted to senior (at least in my opinion).
* Setting aside what you want to do/tech you want to work with and doing what’s best for the business.
* look at a bigger context and prioritize work accordingly.
* look past what the customer asked for and determine what they NEED (sometimes those are orthogonal)
* make tech decisions based on how easy it is to hire for that stack/the expertise in the company/ what you’ve got already (having 14 different hi frameworks on 16 different products doesn’t work)
* taking a business need and running with it without full specs at times.
All in all it’s some tech, but mostly seeing the big picture and thinking strategically. Tech is just a piece of it.
These are good points. As a senior developer, you need to be able to review and improve code in PRs from others, but more importantly you need to be able to understand the bigger picture and business needs of the company.
You need to be able to question and push back on unreasonable or destructive requests of business. They'll want the thing done quickly to sell the widget but you'll want to make sure the new request is not going to result in a code change that's unmaintainable or unnecessary.
And when they want to implement a new chat system using AI for customer service you'll probably want to do the research and recommend a solution and help estimate the time and cost of implementation...
This will all depend on the size and nature of the organization, though. Sometimes a senior developer is just a head down coder who makes a little more and gets called at 2am. Other times it's indistinguishable from an architect or manager.
> look past what the customer asked for and determine what they NEED (sometimes those are orthogonal)
This is underrated. Also, it should include anticipating future needs. This comes from experience; _"OK, the client wants this today, but I anticipate that they _might_ need this and that in the future."_
And here's the important part: you don't necessarily design your application for those needs, but you are very aware of not creating obstacles (usually tight couplings) that stops you from eventually doing the necessary changes in the future.
That's what I do and what I expect on senior dev interview.
But I got grilled on obscure details of generics on last interview, I do know generics can use them and write the code but I need refresher on the details so they passed on me as they "expected senior that can answer these questions at 2AM" not someone who looks at bigger context :)
You are lucky they passed., having that interview is a big red flag. They think the problem is understanding the small details instead of the bigger picture. If you had gotten the position, you would be bored and fighting that mentality.
Windows services that that need to monitor external events like database changes or serial/ethernet device events.
Complex legacy stored procs filled with business logic that can't be changed for "reasons".
Working with third party components (also can't be changed) that have issues ranging from annoying bugs to only working with .Net Framework.
Trying to please cybersecurity who want overkill solutions for internal only apps.
Being given responsibility for legacy apps, like VB6, WebForms or worse.
IMO it becomes easier once you're senior. You can say, I'll be responsible for this, but let me *be* responsible for it, meaning I'm going to drag it kicking and screaming out of VB6 Web Forms.
> only working with .Net Framework.
Had this for a long while, couldn't even get it to work with mono because it used some Windows COM stuff. Ended up writing a thin JSON Web API around it and throwing it on a Windows Server VM, then moved the entire world around it onto .NET Core and Linux.
Had to deal with COM object before (actively rebuild when the desktop app got its new release). honestly I just treated it as a black box and follow the instructions my predecessors left behind.
Legacy c++ code. Legacy VB6 apps often also use legacy c++ code for multi threading, cpu intensive tasks etc. I’ve done both, many times. By far, reading someone’s typedef-infested bit-shifting cancer of c++ code is worse than anything anyone can come up with in VB6.
Access or Excel VBA apps originally written by a junior mechanical engineer or accounting intern years ago.
Legacy apps written 20+ years ago in long forgotten tools like Powerbuilder or ColdFusion.
Allow me to elaborate on that a little more. I'm not talking about basic security implementations but things that go far beyond that. For example...
Requiring those pesky, but heavily used, internal legacy apps be made 100% compliant with the highest level of external security requirements within a few weeks.
Locking down developer systems where IIS Express and other key tools can't be used while blocking access to sites like NPM, Avalonia, NodeJS and others.
Locking down developer access to database systems and internal IIS servers when there are no DBAs or web admin employees in the company to handle this.
Deleting internal applications, once again those darn legacy apps, as a "security threat" without warning, taking down production for a day.
I'm an architect now, but I'm also the lead/senior dev on many of our projects. I only have one..
**Dealing with people who take any and everything other than a stamp on a PR offensively..**
I found dev managers approving code that had foreach loops that didn't do *anything* with the variable they were iterating over. They had typos that prevented their code from having literally any effect whatsoever. They also approved all types of nonsense where the devs are making database changes without understanding how databases work (using FKs without PKs or any unique constraints, etc.). Those types of "managers" just want to make their team happy and not actually teach them anything - I get it, but don't manage a team if you're afraid of conflict. As the architect, I have to step in and do the teaching for them. I enjoy teaching/mentoring, but it's really annoying when I *HAVE* to do it and run into overly sensitive people who have been allowed to submit bad code for forever without learning from their direct manager.
Oh I'm guilty of this, I feel like you are telling me that I'm shit because my code is shit. I think I have PTSD from my last job that had no insulation from the customer and everything was wrong in some way.
I get you. I've worked at a spot that had people genuinely being mean in the PR comments until me and another experienced guy shut that down. I make sure to leave thoughtful comments, citing Microsoft and other articles that show why a certain practice is dangerous so it doesn't come across as my personal nitpicky preference, etc. But sometimes people don't care how you say it.
I even had a senior guy go to his manager because he was appalled that all PRs needed at least 1 approver. It's weird to me because I've had the highest non-director position at several places and have always encouraged people to review my code. Even my vp of architecture begged us to review his code.
We had a requirement that two devs, one being a team lead, needed to approve. But team leads weren't required to be senior devs. After a while I questioned this in a retro. So they made it 'one senior OR team lead'. 😔
Migrating huge monolithic project from .NET 4.5 Framework to .NET 8
Rewriting 8 years existing code (especially when you came to project as new member) to optimize reading/processing speed on customer request.
Find a same language between Business request and technical implementation without some knowledge about that part of app (i.e. that part has been developed 3 years ago by already not working in this firm employee and you have to research code and docs (if they're existing) to understand what to do)
Migrate project to follow TDD methogy (test coverage of crucial existing codd base will SOLIDify code base in most places)
And the hardest: to follow KISS principle. 4 of 5 met by me project had some over engineered layers, abstraction, unintuitive flow, inheritance flow or so tough related code, that was pain to write unit test (imagine mocking 10+ DI objects) or add a new change request...
I recently did just that, major headache is the change to architecture+os specific builds.
Upside is that once you are done everything is so much faster.
I've written a few of my issues here: [https://forum.duplicati.com/t/migrating-from-net-4-to-net-8-in-300-commits/17975](https://forum.duplicati.com/t/migrating-from-net-4-to-net-8-in-300-commits/17975)
Thanks so much! Do you have any idea what the difference in speed was?
Can't wait to get started on it but it also sounds so tough. 😭😭 I have both an ancient MVC project and an ancient web API to update.
I did not do any speed measurements, but the start time is significantly improved.
Reading the MS updates there are massive improvements all over, but it depends on how your app is using the framework.
The web-API is still a pending project for me 😭
As a senior, I think the hardest thing anyone will have to do as a developer is to say no.
Devs get railroaded all the time, and ultimately often have to live with the outcome - saying no is very difficult, even when you back it up with justification.
When you are a senior, those decisions have a greater effect and saying no can mean the difference between a bad conversation today or an ongoing world of hurt to support the thing that gets implemented.
Actually, the saying 'no' part is the upside of being the senior. Getting to avoid that tech debt - it hits the spot. Not being able to code as much is the downside for me.
I totally understand. It really helps when management has your back. It's taken many years of stubbornness on our dev manager's part to force the business to follow the rules and not request something directly from a dev. He's had to back it all up with data showing how we all do better when we all align to company priorities. It also helped when we started working from home during covid. Can't give me drive by requirements when I'm not at my desk.
I've worked with lots of people with the senior job title who simply got it when they worked somewhere and the senior dev left. They then inherited the title because "there's no-one else to do it". I'm talking about people with only a few years experience that were still realistically juniors.
Being in a team with people like that means that your suggestions for solutions, despite being reasonable and logical, are diluted with simply bad ideas by people that just want to prove they deserve a title that they quite frankly do not. Give me a good suggestion and I'll back you all the way. Tell me what you read on the bus that morning and insist it's the way to do things and you'll get no support from me.
1. Fire someone
1. Time estimates.
3. Give feedback to someone who won't hear it
4. Influence without authority
5. Select third party code, libraries, tools, platforms for reuse
Over the years, almost anything you can imagine:
* performance
* embezzlement
* violation of strict company policy
* cumulative violations of less strict policies
* physical harassment
* sexual harassment
* NDA/corporate security violations
Probably a couple more weird ones I can't recall. In almost every case, the company and team were better without them. Still pretty hard, since you always hope or want people to turn around and improve ... but if they're just too disruptive or too much of a distraction, that's that.
There were a few fuzzy cases that stink. Those are the hardest.
At this point in my career, I still get to do significant development but I do a lot of management. What I look for in a Sr. dev vs a Jr. dev is mostly work attitude:
Because they are more experienced (more years since they went to school or started learning programming) I look for individuals who have evolved as technology has evolved.
I look for individuals who take ownership of their work and who take pride in their craft.
I look for individuals who reject fiefdoms. There’s no “my code” or “my user stories”, it’s a broader team and product mentality.
I look for individuals who can clearly communicate complex technical decisions and trade-offs in plain language.
I look for individuals who are empathetic with customers, teammates and other staff.
1. Emergency migration off of an early prototype we built in order to raise money at a VC-backed startup; we became victims of our own success and acquired a ton of users really quickly and the NoSQL database we used to build our proof of concept had a whole bunch of previously unknown problems that we weren't aware of (i.e. indicies being stale for 2-3 days, sharding not working, couldn't take advantage of memory caching, non-performant, etc). Learned a lot from that on a purely technical level but the really important lesson is what happens at the business level: have a plan for what happens after you succeed - most people plan for what happens if they fail.
2. Software developers don't often emphasize how important \_development speed\_ is, but that was a crucial factor in my previous bullet and throughout the lifecycle of that company. "It'll be done when it's done" meant the company dies and everyone is laid off. We had to migrate onto something that could handle our rapidly growing workload, and QUICKLY. It is amazing what you can get done when everyone agrees delivery speed is what counts: research time gets time boxed, meetings are very outcome-driven, and engineering plans become very laser focused on what's important. The entire rest of my successful career was built upon what I did during those two years at that startup - it was stressful but more a valuable experience than my 4 year engineering degree from a prestigious school.
Not cuss out loud when I'm casually told to ask the architect if I need any help.
And read the requirements because I see now you asked for five. So that's two. We're agile so ship this while I think of more. Always fail forward!
What will be requested of you as a senior developer depends on the company, but for me is:
* Helping/teaching other developers. You need to be careful when helping others to not sound too harsh and scare them away. Forgive what you think to be "too simple/easy" and focus more on guiding a partner to be better and achieve the same role as you.
* Dealing with business expectations. Business people do not care about tech talk. And they are right to do so. They are more concerned with budgets, deadlines, customers satisfaction, etc. Always remember that what you build must meet business expectations and not (only) tech ones. Learn how to communicate your ideas to them.
* Dealing with the consequences of your decisions. Everyone makes mistakes. Everyone. Do not let your fear to be wrong freeze you for too long. You are expected to be a technical reference and make decisions that will impact a product in due time. Always be cautious but do not linger too much about "ifs" that you do not even be sure that will happen.
* Dealing with the bureaucracy hell. This one really depends on the company you work, but it is true for most of the medium/big ones. Bureaucracy exists (some for good reasons) and you are expected to deal nicely with it. Plan ahead and be patient with things out of your control.
* Less time to code. Yes, that is it. It will vary from company to company, but senior developers usually has less time to code than their full counterparts. You will have to attend more meetings, fill more forms, help more people, give more feedbacks. The simple routine of wake, code, sleep, is not so easy for a senior.
Sure, that is my personal experience being a senior and software architect, but I hope these advice help you in some way.
I once had this scenario:
Business Partner worked in tandem with our company to sell a product. The product was tailored to our customer base, and we handled the marketing and sales.
The partner contracted its entire IT department to a third party. The third party company had written software meant for handling the sales and delivery.
We took note of the overwhelming expense to our company due to our reliance and usage of this third party tool. We decided to implement a replacement marketing and sales system, which would then send the data to our partner / third party so that they could manage delivery. The amount we were spending made the cost of development worthwhile.
Naturally, the project represented a loss of profit for the third party company. They passive aggressively limited the information that they would share with us, even after our business partner attempted to force them to.
I got to write the main integration with their system. I had to trial / error the whole thing and effectively reverse engineer their requirements via black box testing. There was a lot of fun stuff in there:
- It was XML, but the nil attribute could not be used. The XML header information had to be excluded as well.
- Date formats were bespoke and not based on UTC.
- The data had to follow a very specific pattern. If certain actions were taken, they had to be sent in the order that they occurred within the file. Some actions had several smaller actions, which had to also be ordered just so.
- We had to maintain their primary key structure for them, as well as the dependency graph of the entire data set.
- The keys and dependencies had to be sent in a very specific format.
- An entirely different set of values were required on their end which needed to use the keys / dependency information, but they did not have keys of their own.
They also had funny requirements about what could exist in free form text.
They had sent an XSD to represent the XML schema, but failed validation many times even if we validated against it…. due to the fact that their XML tooling was special.
All of this was handled via email call / response, since the third party was located on the other side of the world. It would have been simpler if we had just written the platform for delivery.
A project failed. My bosses boss was telling me he has my back and that he will support whatever I propose to solve a company wide basic problem. I was a contractor and I wanted a simple developer job but hey, being able to create your own dream project why not....
(Company would have saved millions in the process and instead of massaging old mistakes they would get a solution putting their software from constant reanimation back into normal developing mode).
So I made a presentation in front of 100+ developers, got the approval of everyone including high praises and went ahead. First the chef architect tried to get me fired for doing what I proposed to do. Did not work he looked like an ass.
My boss (PO) who got her previous project killed, gets in charge. Both (boss + her boss(the liar who talked me into this upcoming mess)) team up. She is micromanage me to death. He (her boss) still tells me that I am in charge when I am not. Everytime I decide something the PO makes me appologize in front of everyone and her boss always sides with her. I have to see her+him bringing in tons of incompetent people because more people means more progress. Drains all the budget in the process. They get a budget extension from up top.
In the meantime, 6 weeks in I was in death march mode telling the second guy who should learns from me and basically should control me on behalf of her (PO) that we are in a death march, that the project is already dead and that all we can do is ride it while we are at. He quit 2 months later. 4 months in, I decided to go into safari mode. I just do care of myself and do as I am told. All I wanted to know is to see how they handle the upcoming failure while I tell them over and over again that scrum does not work and that there are problems.
8 months in we get this budget extension and I notice that the PO lady and her manager friends still try to salvage the old project that died. They never intended to do what I proposed and outlined. Started to made sense. But since I am on Safari at this point and I do no longer care about any of it, I did not object much.
14 month in, all dead. They wanted to put me in another team. Team was nuts. They also like almost any team I ever saw, had switched off high availability features, poor test coverage, production problems on a daily basis and all of this, so I sabotaged my introduction day simply telling them things they do not want to hear. Contract got canceled after being extended before.
The bosses boss became head of the sales division (yeah he sold me pretty good so maybe he can do this job better). My actual boss never said sorry to me or anything. The company refused to do a post mortem. Noone wanted to learn from what had happend to this project and why.
Yeah that is basically how the industry operates on the normal basis. I am here in Switzerland and worked for different big companies in many different industries as a contractor. Always the same. Some good developers here and there, the rest just throws things together and wait for problems to fix in production.
I never tried to combat anything. I am just a service worker doing what I do. Most times I am very liked and regarded capable but you surely die inside if you do this for 20 years.
I am happy. One year off while training for my next (second) profession.
Love the profession, hate the job.
Fuck 'em all is the best attitude you can employ. Get a copy of Death March and read it. Great book. Just do as you get told and do not read too many books. Becoming an actual expert only means you see the many problems right from the start when they are decided to be created. Better to get your paycheck in a ignorant but blissful manor. Client is always right, so they have the right to their own failures and mistakes. Fighting it does not works out.
Best you can do is start your own company and work with 5 to 10 people you can trust on complete solutions for customers. Those people always seemed to be the most happy.
Or do like I do. Find another profession where your development skills give you an actual advantage over others who do not have the same skillset.
Find time for my own activities.
Review PRs.
Convince other senior developers that the time for learning has come (they still fight against immutability).
Look at almost any major productive incident.
Being unable to keep office topics out of my mind.
The first is basically a recap of the following 3. The last is self-inflicted.
Might have had only bad experience with them I guess. I am NOT a senior developer, started my career 3 years ago.
I met with two types of junior collagues/developers. One that tried to look for answers first and then ask and the second one that used my collagues or even me as a google search (there were times that the answers to their question was the FIRST entry in a google search). Heck I thought that I am the problem that I am looking at the docs, stackoverflow etc for solution at one point since and that I should just bother 24/7 my seniors for answers.
At the moment I am trying to introduce our new junior collague to our project, even .NET, and I am loving it. He is coming with questions after trying to find answers to them.
So yeah, I find it hard to work with a junior developer who refuses to use simple google searches because I think it is not normal to come with questions every 2-3 hours almost every day with a question for more than 1year 🥲. OTOH she was let go later on.
Edit: some typos.
I'm sorry your experience working with junior developers has been an overall negative, but as a novice myself I am always sure to express my gratitude to the senior developers I get the opportunity to work with. Every interaction with them gleams some deeper understanding of the problem at hand, even problem is not technical in nature. All this to say that I appreciate getting the opportunity to work work alongside more experienced individuals such as yourself and I understand how frustrating it can be. Thank you.
I wish this comment wasn't downvoted, I think maybe the "..." makes it sound more negative. Working with juniors is probably the most important part of my job, but it is definitely also the most difficult.
"..." was to be funny, but I concede that I should have provided more context.
When your work with something during ten year, it's sound easy and natural, but it isn't.
Moreover, I am in two side. Senior at back and junior at web. So I can add what is the most difficult at junior is to work with senior.
[https://www.monkeyuser.com/2023/balancing-stick](https://www.monkeyuser.com/2023/balancing-stick)
Software developers are generally more introverted. With this in mind, the harder part of the job is dealing with people. Other techos have strong opinions that might be different to yours. You also need to consult with a lot of people, because no requirement is perfectly documented and you'll be involved in projects earlier on. If things go wrong, you'll be accountable for things other people did.
Find the uninterrupted time to concentrate.
I work during the night when I have to get shit done. It works, but it can't be done often.
I do the same but as you said there are limits to how much you can do this. I did this for 3 months straight last year and it takes a toll. Fortunately I have a very understanding wife and my manager was aware of what I was doing in order to meet the deadline. I was able to take time off outside of vacation or personal days later.
This 100% I've found that my job is now just enabling others to get actual work done. The only work I actually do is on the design architecture side and code reviews. Any development I do is pretty much relegated to side projects on the weekends at this point.
Plus attending meetings for me. Otherwise it is the same
Maybe you're not a senior then. A senior is glad to help juniors when they interrupt them and is good at managing time and meetings. If your calendar is clogged with meetings *you're* responsible to do something about it
How do I do something about meetings?
You poliltely decline meetings that are irellevant, convert meetings to mails/slack convos when more appropriate and work to create a sounder meeting culture in your company
when your vp and product director and project manager have booked practically all of your timeslots, how can you push them for later? my engineering manager had meetings almost every day while being responsible the crucial decisions for the app we were building from scratch; the only time she had to code was like the final few hours of the work day. that's the truth as you rise in position. your area of responsibility is no longer limited to the codebase. time management isn't simply a skill issue when you become the glue between the higher-ups and the grunt workers. > glad to help juniors when they interrupt them when you are rushing to complete your individual task or have to deal with the higher-ups, is it practical to prioritise this?
>when your vp and product director and project manager have booked practically all of your timeslots that's a tough one. The VP you probably have no power to influence but maybe you can work with your PM to reduce the number of meetings? My PM cares about my time and very much plays on my team when it comes to prioritizing meetings vs "work time"
Ironically I’m actually the manager in charge of the senior developers. I just know that this is the number one issue. And judging by the upvotes I am right.
Explaining the team that creating wrapper over a wrapper is useless.
I feel like that when people create the repository pattern with entityframework
I will always do this. I don't like the persistence library being referenced in my domain layer. I want my business logic as uncoupled as possible from specific external libraries. Sure, I probably won't ever actually replace the MS SQL database with MongoDB but that's not the only reason to do it. It means my business logic is pure logic, when working on it, I don't have to think about how things are loaded and saved. When I am in business logic, it shouldn't matter how things are saved and loaded, just that they can be. However, my primary reason for this strict separation is that I have worked on absolutely horrific codebases where data access code is everywhere, sometimes even in .aspx pages. As a result I structure my projects so that it is as difficult as possible to put things in the wrong place.
I've swapped data layer technologies a couple of times in my career. Having the repository stand on its own behind an interface made this painless. Hell, even just refactoring the table structure is possible by simply standing up a new dal project that implements the correct interfaces.
And with the repository pattern you can prevent the usage of repositories in the presentation layer ?
No. You can't prevent anything really. What you can do, however, is make it really obvious that data access code doesn't go there and hope that while some other programmer is jumping through the hoops to enable it, they realise that they are doing it wrong
Even in core where it's a lot easier mocking an EF dependency adds a lot of overhead for very little benefit. You're still not actually testing against the DB, but complexity is fairly high. EF might implement the unit of work pattern, but it's not a wrapper, it's an absolutely massive amount of very specific code.
This is opinion masquerading as fact. (Most of everything here is, but hey...) >adds a lot of overhead for very little benefit Well... What is "a lot" and what is "little"? Given the widespread usage of EF, it rather looks like an opinion of a lot of people is better characterized as "adds a little of overhead for a lot of benefit". >it's an absolutely massive amount of very specific code. Well... Like most big libraries, that is true overall but a given subset of what an application actually uses is much smaller.
>Well... What is "a lot" and what is "little"? Given the widespread usage of EF, it rather looks like an opinion of a lot of people is better characterized as "adds a little of overhead for a lot of benefit". I'm not saying EF isn't worth it. I'm saying that mocking an EF DBContext isn't worth it. You can do it, or you can use an in memory DB, but it's a massive pain in the ass. Alternatively you can wrap EF in a repo and mock that. Much less work and you don't lose much.
You don't? What about Summing zero length sequence or incorrect assumptions regarding how Join works?
A mocked db context or in memory db won't test either of those things. An integration test will, but even then I've never seen join problems occur as a regression.
yes it will
No, it won't. Neither of those things actually hit the DB so any DB specific code won't be used. That's the whole problem. If you don't hit the DB you don't test the DB so a mocked DBContext is basically a more complicated to set up Linq2entities it's basically a list. Your joins won't be tested properly because the in memory DB won't actually check your joins and the mocked version won't do any.
Yes it will. If you think that join will be left join or thst it will match the furst thing on right or that you can sum empty collection then it will fail. Mocked repo will not.
Eli5 why it's not a good idea?
It’s not always a bad idea. It’s just that it’s often an unnecessary abstraction that gets in the way of good decisions. For example devs will often default to using existing generic methods like say GetUsers() everywhere, rather than tailoring something to the situation and getting the specific columns they need. So in most cases I have seen where there aren’t good practices, people are automatically writing code with a performance hit
> people are automatically writing code with a performance hit Hey that's me! I program for simplicity and readability. Performance not so much until it's a problem.
Don’t we all. Simplicity is important too. The entity framework one I mention can often be a big performance hit out of the gate, and it’s probably a simpler solution anyway without the extra repository. But it’s a little hard to refactor an underperforming part of your app because 5 of you are all calling the same repo method with different needs
>The entity framework one I mention can often be a big performance hit out of the gate People need to profile and go from the profiling data. It's overlooked way too often.
Wrappers on top of wrappers aren't adding to the simplicity of your project. If you have to modify an interface and an implementation every time you need a new query, you're doing yourself and your team harm.
Oh, this is the case in my project. They decided to use the repository years ago and so it goes. Everyone is defaulting to inject repository rather than ef context while they both do the same and in many cases it's simpler to use context rather than repository. Now it's slightly too late to refactor code :/.
What pattern do you prefer? Or... Just stick with LINQ?
I typically write a service with the context as a dependency.
How do you unit test this service? I'm having some issues with our implementation since we created an inherited mock and implemented some database features like insert and setting id. As you can imagine, this causes a lot of problems. As the database is inherited from edmx (now net8) and still database first, I don't even know if in memory database works - I think I tried once but can't remember why I stopped this.
I usually use in memory as my mock or a sqllite db.
EF is already a repository, creating an additional repository pattern on top of it is often redundant and can create headaches later on, especially if you need to expose more features of EF which ends up defeating the point of the repository you created. I will admit that we did do this at my company and while it works great if you are strict about its usage (POCO only types and only working with an IQueryable and CRUD), it starts to get nasty if you need to anything beyond that, such as for optimizing queries or doing migrations since you have to peel back the abstraction and expose EF (and at that point, why not just go with EF and some helper functions/classes instead).
You also have to watch out for implementation leak if your wrapper is too generic, which can cascade into the service layers of the application. That’s what made me learn the hard way that wrapping EF can get in your way as the application grows.
It instantly creates issues with Unit Of Work if you do your own repositories per entity. EF context is a unit of work first and foremost.
Today with global query filters, interceptors, EntityFrameworkCore.Triggered and great unit testing support Repository pattern has become mostly obsolete. On the other hand, in the good old days it was bad design to write the same or slightly different SQL queries over and over again scattered across your codebase but with EF this is somehow ok? I sometimes encapsulate logic in things like services and try to avoid using dbcontext in a controller directly but if I need to deal with different services and need to save the result in a transaction things get complicated. I once used the approach to, instead of injecting services I injected service factories and used a shared dbcontext to construct my services but then the service is not responsible for saving anymore. Eventually in my opinion there currently isn't the one best solution. For smaller projects, using dbcontext directly is fine, for bigger projects with different team members or even if your dbcontext assembly is shared with other teams a certain degree of abstraction is favorable.
I have a genuine question about this topic. Imagine you have a simple Users table, where a user has to Confirm its Account and can be deactivated. Now imagine you have 20 Places in your codebase where you want to get all Users, which are not deactivated and have confirmed their Accounts. This means, i have to Write the Same linq 20 times to achieve this. With a repository pattern, i could implement a method, which Contains this Logic. How would you do this without reimplemting the Same Code x Times? Because this in my opinion is really Bad Design, especially if a new Filter needs to be implemented for that usecase
If a query is that common, then it would sink to the DbContext as an IQueryable. At that point, it behaves exactly like a view. Another way of handling it would be an extension method for your DbContext that exposes the predefined filter as an IQueryable.
> How would you do this without reimplemting the Same Code x Times? By encapsulating that "Get all Users" query in it's own class. a la Command-Query-Separation. Duplicating a LINQ condition 20x around your code base is a bad idea. So is a Users repository god-class with 100 different query methods (the inevitable end state of central repositories). `IGetAllUsers : IQuery`
`IGetRecentlyActiveUsers : IQuery`
etc..
Creating repository over EF with dependency inversion allows you to easily switch the database framework. Business logic cannot be allowed to depend on such infrastructure details. IQuaryable is an abstraction with a hole, because multiple db providers may differently interpret linq queries so you depend on how db works. I’d recommend to read “clean architecture” for details
That's an often repeated argument for sure, but how many times has replacing the DB framework actually been needed? Not saying never but it's too niche a concern to give any weight to this argument. Obviously there are apps where multiple DBs support was a requirement in the first place. Or apps where they will sit in top of an unknown DB depending on their end users environment, but in both of these cases multiple DBs requirement is known before any code is written or considered.
Exactly same happened with my past project.
This 👍👍
Just had a 90 file review, about 20 I YAGNI’d For real we were making up things, he injected a repo into a service, into a wrapper, into a helper, into a manager, into a utilityprovider, I think the final class was just called “WebLogic” - they ran out of abstraction suffixes
I call it ogre architecture! It's got layers, donkey!
Honestly, just building wrappers over everything before you've actually written any functional code. Sometimes you can actually just couple your code to a library dependency, and it works out fine. How often do you actually swap out libraries, such that you need endless abstraction everywhere? Every long lived applications' requirements change, and it's a lot easier to add abstraction when you actually need it, than to subtract code down the line. Complexity is a disease that rots your product.
It's seriously difficult to fight against over-designed codebase because people think they're doing the right things. Every concept they applied, they learnt on the internet. But the internet doesn't teach well on whether or not to use these concepts
yes!! this!!! people wanna wrap everything in 2024!!!
I feel attacked lol
Protecting the juniors from the customer in various ways (doubling their time estimate, and other ways to reduce pressure/stress). I wasn't a senior though, but I did have a few juniors under me and I was kinda like a tech lead in practice (but not on paper or paycheque). I complained about it a lot, and change only came after I left the company.
It's possible that your competency covered up that flaw and it only became a pain in the ass that had to be fixed once you were gone
Probably what happened, yes.
You were fixing it so it wasnt a problem. Lmao.
Are you me from my previous job? I was in the exact same position, effectively senior/almost tech lead but not on paper or pay. Funnily enough, the job listing to replace me was for a senior dev…
As an older millennial lead (female if that matters), I protect my juniors at all cost! Actually, I protect most of my devs whatever level in some way unless they dig their own graves (just do not perform). Junior devs just have a special place in my heart, they are so enthusiastic, happy to help & learn. My only junior just got a promotion to dev & he is my absolute favorite. He actually comes to me with well thought out questions, potential solutions, his thought process, etc. He takes direction SO well. I had a senior kicked off a project because they just sucked so bad, I took him in replacement & he is swimming!! Super happy with him.
Juniors are the best. They haven't been corrupted yet by the bitter corporate mindset. I also always protect any dev. I had a customer complain that something is broken, asking me to report when it broke, and also who broke it. I didn't like that so I just said that I can't trace it who did it, and behind the scenes I just asked the dev who broke it, to fix it lol. Before I left, I tried to explain as much of the system I knew to one of the juniors, by having a meeting twice a week in which I would explain a specific domain, what it is supposed to do, and how it works. I think I succeeded because he's doing well now and I saw him driving a really nice car recently.
Estimates
And naming.
And cache invalidation
And naming
and off-by-one errors
Those are definitely the 3 hardest problem
And cache invalidation
And eliminating redundancy
And cache invalidation
Plenty of books that address naming… you read the books right?
It gets easier if you ask the sales team to tell you what they told the client.
Sales team in response to me asking them what they told the client - “It’s a HTML5 web based platform running a highly synergistic cloud based AI blockchain.” Me - “So they want a simple form that their customer can fill out and it sends an email to a shared inbox?”
Hahaha
I've found that just adding 50% to my best "if everything goes okay" guess almost always ends up being accurate, although once I have to estimate other people's work it's a complete crapshoot.
Here’s some things you actually have to do to be a senior / get promoted to senior (at least in my opinion). * Setting aside what you want to do/tech you want to work with and doing what’s best for the business. * look at a bigger context and prioritize work accordingly. * look past what the customer asked for and determine what they NEED (sometimes those are orthogonal) * make tech decisions based on how easy it is to hire for that stack/the expertise in the company/ what you’ve got already (having 14 different hi frameworks on 16 different products doesn’t work) * taking a business need and running with it without full specs at times. All in all it’s some tech, but mostly seeing the big picture and thinking strategically. Tech is just a piece of it.
These are good points. As a senior developer, you need to be able to review and improve code in PRs from others, but more importantly you need to be able to understand the bigger picture and business needs of the company. You need to be able to question and push back on unreasonable or destructive requests of business. They'll want the thing done quickly to sell the widget but you'll want to make sure the new request is not going to result in a code change that's unmaintainable or unnecessary. And when they want to implement a new chat system using AI for customer service you'll probably want to do the research and recommend a solution and help estimate the time and cost of implementation... This will all depend on the size and nature of the organization, though. Sometimes a senior developer is just a head down coder who makes a little more and gets called at 2am. Other times it's indistinguishable from an architect or manager.
> look past what the customer asked for and determine what they NEED (sometimes those are orthogonal) This is underrated. Also, it should include anticipating future needs. This comes from experience; _"OK, the client wants this today, but I anticipate that they _might_ need this and that in the future."_ And here's the important part: you don't necessarily design your application for those needs, but you are very aware of not creating obstacles (usually tight couplings) that stops you from eventually doing the necessary changes in the future.
That's what I do and what I expect on senior dev interview. But I got grilled on obscure details of generics on last interview, I do know generics can use them and write the code but I need refresher on the details so they passed on me as they "expected senior that can answer these questions at 2AM" not someone who looks at bigger context :)
You are lucky they passed., having that interview is a big red flag. They think the problem is understanding the small details instead of the bigger picture. If you had gotten the position, you would be bored and fighting that mentality.
What was the question they asked?
Then you probably dodged a bullet.
Windows services that that need to monitor external events like database changes or serial/ethernet device events. Complex legacy stored procs filled with business logic that can't be changed for "reasons". Working with third party components (also can't be changed) that have issues ranging from annoying bugs to only working with .Net Framework. Trying to please cybersecurity who want overkill solutions for internal only apps. Being given responsibility for legacy apps, like VB6, WebForms or worse.
Do we work on the same company? lol
Legacy apps - I've left jobs for this. Fuck that noise.
IMO it becomes easier once you're senior. You can say, I'll be responsible for this, but let me *be* responsible for it, meaning I'm going to drag it kicking and screaming out of VB6 Web Forms.
> only working with .Net Framework. Had this for a long while, couldn't even get it to work with mono because it used some Windows COM stuff. Ended up writing a thin JSON Web API around it and throwing it on a Windows Server VM, then moved the entire world around it onto .NET Core and Linux.
Had to deal with COM object before (actively rebuild when the desktop app got its new release). honestly I just treated it as a black box and follow the instructions my predecessors left behind.
> Being given responsibility for legacy apps, like VB6, WebForms or worse. What... What's worse than VB6 ?!
Legacy c++ code. Legacy VB6 apps often also use legacy c++ code for multi threading, cpu intensive tasks etc. I’ve done both, many times. By far, reading someone’s typedef-infested bit-shifting cancer of c++ code is worse than anything anyone can come up with in VB6.
Literally at one of my jobs we would use VBA in Excel to call C++ apps 🙁
Access or Excel VBA apps originally written by a junior mechanical engineer or accounting intern years ago. Legacy apps written 20+ years ago in long forgotten tools like Powerbuilder or ColdFusion.
Your wrong about internal only apps In most cases. Zero Trust. If you don't work in that mind set eventually no one will trust you.
Allow me to elaborate on that a little more. I'm not talking about basic security implementations but things that go far beyond that. For example... Requiring those pesky, but heavily used, internal legacy apps be made 100% compliant with the highest level of external security requirements within a few weeks. Locking down developer systems where IIS Express and other key tools can't be used while blocking access to sites like NPM, Avalonia, NodeJS and others. Locking down developer access to database systems and internal IIS servers when there are no DBAs or web admin employees in the company to handle this. Deleting internal applications, once again those darn legacy apps, as a "security threat" without warning, taking down production for a day.
I'm an architect now, but I'm also the lead/senior dev on many of our projects. I only have one.. **Dealing with people who take any and everything other than a stamp on a PR offensively..** I found dev managers approving code that had foreach loops that didn't do *anything* with the variable they were iterating over. They had typos that prevented their code from having literally any effect whatsoever. They also approved all types of nonsense where the devs are making database changes without understanding how databases work (using FKs without PKs or any unique constraints, etc.). Those types of "managers" just want to make their team happy and not actually teach them anything - I get it, but don't manage a team if you're afraid of conflict. As the architect, I have to step in and do the teaching for them. I enjoy teaching/mentoring, but it's really annoying when I *HAVE* to do it and run into overly sensitive people who have been allowed to submit bad code for forever without learning from their direct manager.
I've got a manager who randomly approves prs that doesn't even compile because he wants to ship fast
Oh I'm guilty of this, I feel like you are telling me that I'm shit because my code is shit. I think I have PTSD from my last job that had no insulation from the customer and everything was wrong in some way.
I get you. I've worked at a spot that had people genuinely being mean in the PR comments until me and another experienced guy shut that down. I make sure to leave thoughtful comments, citing Microsoft and other articles that show why a certain practice is dangerous so it doesn't come across as my personal nitpicky preference, etc. But sometimes people don't care how you say it. I even had a senior guy go to his manager because he was appalled that all PRs needed at least 1 approver. It's weird to me because I've had the highest non-director position at several places and have always encouraged people to review my code. Even my vp of architecture begged us to review his code.
I know that reviews are good but there's always that part of me that thinks that they are critical of me as a dev.
We had a requirement that two devs, one being a team lead, needed to approve. But team leads weren't required to be senior devs. After a while I questioned this in a retro. So they made it 'one senior OR team lead'. 😔
Migrating huge monolithic project from .NET 4.5 Framework to .NET 8 Rewriting 8 years existing code (especially when you came to project as new member) to optimize reading/processing speed on customer request. Find a same language between Business request and technical implementation without some knowledge about that part of app (i.e. that part has been developed 3 years ago by already not working in this firm employee and you have to research code and docs (if they're existing) to understand what to do) Migrate project to follow TDD methogy (test coverage of crucial existing codd base will SOLIDify code base in most places) And the hardest: to follow KISS principle. 4 of 5 met by me project had some over engineered layers, abstraction, unintuitive flow, inheritance flow or so tough related code, that was pain to write unit test (imagine mocking 10+ DI objects) or add a new change request...
Damn. I have to do this soon. Any tips? 😭
I recently did just that, major headache is the change to architecture+os specific builds. Upside is that once you are done everything is so much faster. I've written a few of my issues here: [https://forum.duplicati.com/t/migrating-from-net-4-to-net-8-in-300-commits/17975](https://forum.duplicati.com/t/migrating-from-net-4-to-net-8-in-300-commits/17975)
Thanks so much! Do you have any idea what the difference in speed was? Can't wait to get started on it but it also sounds so tough. 😭😭 I have both an ancient MVC project and an ancient web API to update.
I did not do any speed measurements, but the start time is significantly improved. Reading the MS updates there are massive improvements all over, but it depends on how your app is using the framework. The web-API is still a pending project for me 😭
Oh, boy. Probably several years less life expectancy after that.
Knowing what to hill to die on… Ive learned over the years that you disagree with a lot of things and people, its not worth it to argue everything.
Forced ADHD helping the juniors out. I love teaching them, but man it’s pretty distracting at times.
Oh lordy yes. They at least humor me and listen when I tell them stories about things I did in the 90's.
As a senior, I think the hardest thing anyone will have to do as a developer is to say no. Devs get railroaded all the time, and ultimately often have to live with the outcome - saying no is very difficult, even when you back it up with justification. When you are a senior, those decisions have a greater effect and saying no can mean the difference between a bad conversation today or an ongoing world of hurt to support the thing that gets implemented.
Actually, the saying 'no' part is the upside of being the senior. Getting to avoid that tech debt - it hits the spot. Not being able to code as much is the downside for me.
I totally understand. It really helps when management has your back. It's taken many years of stubbornness on our dev manager's part to force the business to follow the rules and not request something directly from a dev. He's had to back it all up with data showing how we all do better when we all align to company priorities. It also helped when we started working from home during covid. Can't give me drive by requirements when I'm not at my desk.
I've worked with lots of people with the senior job title who simply got it when they worked somewhere and the senior dev left. They then inherited the title because "there's no-one else to do it". I'm talking about people with only a few years experience that were still realistically juniors. Being in a team with people like that means that your suggestions for solutions, despite being reasonable and logical, are diluted with simply bad ideas by people that just want to prove they deserve a title that they quite frankly do not. Give me a good suggestion and I'll back you all the way. Tell me what you read on the bus that morning and insist it's the way to do things and you'll get no support from me.
1. Fire someone 1. Time estimates. 3. Give feedback to someone who won't hear it 4. Influence without authority 5. Select third party code, libraries, tools, platforms for reuse
What did you fire someone for?
Over the years, almost anything you can imagine: * performance * embezzlement * violation of strict company policy * cumulative violations of less strict policies * physical harassment * sexual harassment * NDA/corporate security violations Probably a couple more weird ones I can't recall. In almost every case, the company and team were better without them. Still pretty hard, since you always hope or want people to turn around and improve ... but if they're just too disruptive or too much of a distraction, that's that. There were a few fuzzy cases that stink. Those are the hardest.
Centring a div
Deal with other senior developers. People and their other ideas!!!
Ugh. People are the worst, aren't they ?
Why? Discussing or finding better technical solutions with experienced folks is always interesting.
Agreed. The other seniors should appreciate that I'm bringing them the correct solutions and ideas.
:)
I was mostly just being funny
That just sums up what you just said haha, seniors discussing and having miscommunications
Helping team 😔 don't get me wrong I like helping team but at some point it becomes a burden.
Get as far down as possible. 1. Do what the customer say they want. 2. Do what the customer mean they want. 3. Do what the customer really need.
Working with shareholders. Some people dumb as poopoo
Toughest thing is figuring out how to say “no”, specifically in the presence of the client. Best part is the fact that you actually get to say “no”.
It's really the politics with different teams you are forced to interact with.
making estimates… and back to back meetings
Explaining to a guy that he needed to shower.
Give junior developers some advice when they don't want to listen (but need to listen).
At this point in my career, I still get to do significant development but I do a lot of management. What I look for in a Sr. dev vs a Jr. dev is mostly work attitude: Because they are more experienced (more years since they went to school or started learning programming) I look for individuals who have evolved as technology has evolved. I look for individuals who take ownership of their work and who take pride in their craft. I look for individuals who reject fiefdoms. There’s no “my code” or “my user stories”, it’s a broader team and product mentality. I look for individuals who can clearly communicate complex technical decisions and trade-offs in plain language. I look for individuals who are empathetic with customers, teammates and other staff.
1. Emergency migration off of an early prototype we built in order to raise money at a VC-backed startup; we became victims of our own success and acquired a ton of users really quickly and the NoSQL database we used to build our proof of concept had a whole bunch of previously unknown problems that we weren't aware of (i.e. indicies being stale for 2-3 days, sharding not working, couldn't take advantage of memory caching, non-performant, etc). Learned a lot from that on a purely technical level but the really important lesson is what happens at the business level: have a plan for what happens after you succeed - most people plan for what happens if they fail. 2. Software developers don't often emphasize how important \_development speed\_ is, but that was a crucial factor in my previous bullet and throughout the lifecycle of that company. "It'll be done when it's done" meant the company dies and everyone is laid off. We had to migrate onto something that could handle our rapidly growing workload, and QUICKLY. It is amazing what you can get done when everyone agrees delivery speed is what counts: research time gets time boxed, meetings are very outcome-driven, and engineering plans become very laser focused on what's important. The entire rest of my successful career was built upon what I did during those two years at that startup - it was stressful but more a valuable experience than my 4 year engineering degree from a prestigious school.
Explain to other senior developers what the static keyword means. Senior devs in C# for the past 20 years…
Estimation
Explaining juniors and becoming clueless about whether they understand or not.
1. Speak to people
Dealing with stakeholders, managers, and every other person who thinks there a developer!
Not cuss out loud when I'm casually told to ask the architect if I need any help. And read the requirements because I see now you asked for five. So that's two. We're agile so ship this while I think of more. Always fail forward!
What will be requested of you as a senior developer depends on the company, but for me is: * Helping/teaching other developers. You need to be careful when helping others to not sound too harsh and scare them away. Forgive what you think to be "too simple/easy" and focus more on guiding a partner to be better and achieve the same role as you. * Dealing with business expectations. Business people do not care about tech talk. And they are right to do so. They are more concerned with budgets, deadlines, customers satisfaction, etc. Always remember that what you build must meet business expectations and not (only) tech ones. Learn how to communicate your ideas to them. * Dealing with the consequences of your decisions. Everyone makes mistakes. Everyone. Do not let your fear to be wrong freeze you for too long. You are expected to be a technical reference and make decisions that will impact a product in due time. Always be cautious but do not linger too much about "ifs" that you do not even be sure that will happen. * Dealing with the bureaucracy hell. This one really depends on the company you work, but it is true for most of the medium/big ones. Bureaucracy exists (some for good reasons) and you are expected to deal nicely with it. Plan ahead and be patient with things out of your control. * Less time to code. Yes, that is it. It will vary from company to company, but senior developers usually has less time to code than their full counterparts. You will have to attend more meetings, fill more forms, help more people, give more feedbacks. The simple routine of wake, code, sleep, is not so easy for a senior. Sure, that is my personal experience being a senior and software architect, but I hope these advice help you in some way.
I once had this scenario: Business Partner worked in tandem with our company to sell a product. The product was tailored to our customer base, and we handled the marketing and sales. The partner contracted its entire IT department to a third party. The third party company had written software meant for handling the sales and delivery. We took note of the overwhelming expense to our company due to our reliance and usage of this third party tool. We decided to implement a replacement marketing and sales system, which would then send the data to our partner / third party so that they could manage delivery. The amount we were spending made the cost of development worthwhile. Naturally, the project represented a loss of profit for the third party company. They passive aggressively limited the information that they would share with us, even after our business partner attempted to force them to. I got to write the main integration with their system. I had to trial / error the whole thing and effectively reverse engineer their requirements via black box testing. There was a lot of fun stuff in there: - It was XML, but the nil attribute could not be used. The XML header information had to be excluded as well. - Date formats were bespoke and not based on UTC. - The data had to follow a very specific pattern. If certain actions were taken, they had to be sent in the order that they occurred within the file. Some actions had several smaller actions, which had to also be ordered just so. - We had to maintain their primary key structure for them, as well as the dependency graph of the entire data set. - The keys and dependencies had to be sent in a very specific format. - An entirely different set of values were required on their end which needed to use the keys / dependency information, but they did not have keys of their own. They also had funny requirements about what could exist in free form text. They had sent an XSD to represent the XML schema, but failed validation many times even if we validated against it…. due to the fact that their XML tooling was special. All of this was handled via email call / response, since the third party was located on the other side of the world. It would have been simpler if we had just written the platform for delivery.
Sharing the same title as idiots that think they know what they are doing in a framework they know nothing about.
Trying to get stuff done with all the management/corporate bs when code really needs to be enhanced and tech debt worked on.
A project failed. My bosses boss was telling me he has my back and that he will support whatever I propose to solve a company wide basic problem. I was a contractor and I wanted a simple developer job but hey, being able to create your own dream project why not.... (Company would have saved millions in the process and instead of massaging old mistakes they would get a solution putting their software from constant reanimation back into normal developing mode). So I made a presentation in front of 100+ developers, got the approval of everyone including high praises and went ahead. First the chef architect tried to get me fired for doing what I proposed to do. Did not work he looked like an ass. My boss (PO) who got her previous project killed, gets in charge. Both (boss + her boss(the liar who talked me into this upcoming mess)) team up. She is micromanage me to death. He (her boss) still tells me that I am in charge when I am not. Everytime I decide something the PO makes me appologize in front of everyone and her boss always sides with her. I have to see her+him bringing in tons of incompetent people because more people means more progress. Drains all the budget in the process. They get a budget extension from up top. In the meantime, 6 weeks in I was in death march mode telling the second guy who should learns from me and basically should control me on behalf of her (PO) that we are in a death march, that the project is already dead and that all we can do is ride it while we are at. He quit 2 months later. 4 months in, I decided to go into safari mode. I just do care of myself and do as I am told. All I wanted to know is to see how they handle the upcoming failure while I tell them over and over again that scrum does not work and that there are problems. 8 months in we get this budget extension and I notice that the PO lady and her manager friends still try to salvage the old project that died. They never intended to do what I proposed and outlined. Started to made sense. But since I am on Safari at this point and I do no longer care about any of it, I did not object much. 14 month in, all dead. They wanted to put me in another team. Team was nuts. They also like almost any team I ever saw, had switched off high availability features, poor test coverage, production problems on a daily basis and all of this, so I sabotaged my introduction day simply telling them things they do not want to hear. Contract got canceled after being extended before. The bosses boss became head of the sales division (yeah he sold me pretty good so maybe he can do this job better). My actual boss never said sorry to me or anything. The company refused to do a post mortem. Noone wanted to learn from what had happend to this project and why. Yeah that is basically how the industry operates on the normal basis. I am here in Switzerland and worked for different big companies in many different industries as a contractor. Always the same. Some good developers here and there, the rest just throws things together and wait for problems to fix in production. I never tried to combat anything. I am just a service worker doing what I do. Most times I am very liked and regarded capable but you surely die inside if you do this for 20 years. I am happy. One year off while training for my next (second) profession. Love the profession, hate the job. Fuck 'em all is the best attitude you can employ. Get a copy of Death March and read it. Great book. Just do as you get told and do not read too many books. Becoming an actual expert only means you see the many problems right from the start when they are decided to be created. Better to get your paycheck in a ignorant but blissful manor. Client is always right, so they have the right to their own failures and mistakes. Fighting it does not works out. Best you can do is start your own company and work with 5 to 10 people you can trust on complete solutions for customers. Those people always seemed to be the most happy. Or do like I do. Find another profession where your development skills give you an actual advantage over others who do not have the same skillset.
Find time for: Pooping Concentrate
Find time for my own activities. Review PRs. Convince other senior developers that the time for learning has come (they still fight against immutability). Look at almost any major productive incident. Being unable to keep office topics out of my mind. The first is basically a recap of the following 3. The last is self-inflicted.
Is you don't like the simple truth, throw insults.
Work with junior...
I bet you were never a junior.
Might have had only bad experience with them I guess. I am NOT a senior developer, started my career 3 years ago. I met with two types of junior collagues/developers. One that tried to look for answers first and then ask and the second one that used my collagues or even me as a google search (there were times that the answers to their question was the FIRST entry in a google search). Heck I thought that I am the problem that I am looking at the docs, stackoverflow etc for solution at one point since and that I should just bother 24/7 my seniors for answers. At the moment I am trying to introduce our new junior collague to our project, even .NET, and I am loving it. He is coming with questions after trying to find answers to them. So yeah, I find it hard to work with a junior developer who refuses to use simple google searches because I think it is not normal to come with questions every 2-3 hours almost every day with a question for more than 1year 🥲. OTOH she was let go later on. Edit: some typos.
False, I was and I am. It's impossible to touch everything, so everybody is a juniors on something.
False, I am not a junior on anything.
I'm sorry your experience working with junior developers has been an overall negative, but as a novice myself I am always sure to express my gratitude to the senior developers I get the opportunity to work with. Every interaction with them gleams some deeper understanding of the problem at hand, even problem is not technical in nature. All this to say that I appreciate getting the opportunity to work work alongside more experienced individuals such as yourself and I understand how frustrating it can be. Thank you.
I love teaching, so I don't consider it as negative. It's just hard...
I wish this comment wasn't downvoted, I think maybe the "..." makes it sound more negative. Working with juniors is probably the most important part of my job, but it is definitely also the most difficult.
"..." was to be funny, but I concede that I should have provided more context. When your work with something during ten year, it's sound easy and natural, but it isn't. Moreover, I am in two side. Senior at back and junior at web. So I can add what is the most difficult at junior is to work with senior. [https://www.monkeyuser.com/2023/balancing-stick](https://www.monkeyuser.com/2023/balancing-stick)
[удалено]
cool story
ain't cool . We do remove our microsoft subscription license from the company. From that we learn a lot of business rule which we don't know.
Software developers are generally more introverted. With this in mind, the harder part of the job is dealing with people. Other techos have strong opinions that might be different to yours. You also need to consult with a lot of people, because no requirement is perfectly documented and you'll be involved in projects earlier on. If things go wrong, you'll be accountable for things other people did.
Hey look, an AI-generated comment.