Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
thotsky
Jun 7, 2005

hot to trot
Working on multiple projects at once has a ton of downsides, and very few upsides. Don't do it. Also, if you have significant downtime on a project you or someone above you are working that project wrong.

Maybe see if they are willing to schedule the internal project for after you have finished your time on the client project.

thotsky fucked around with this message at 06:51 on Sep 1, 2022

Adbot
ADBOT LOVES YOU

thotsky
Jun 7, 2005

hot to trot

steckles posted:

I guess I'm just venting here, but whatever...

I was promoted to VP of Engineering about 18 months ago and hiring dev talent is one of my responsibilities. I did quite a bit of hiring before, but now it's actually in my job description. The company is only 60-70 people, but has competitive compensation and the CEO, CTO, and CHRO all understand that good benefits help keep people around. Aside from extended medical, stock options, flexible hours, and generous vacation, we offer permanent WFH with a decent home office budget if you want it, and everyone is committed to working no more than 40 hours a week. Heck, the company even sent a bunch of people to a music festival a while back and picked up everyone's wristbands and drink tickets. No investors to gripe about stuff either.

People seem happy and turnover is very low, except that we've lost three developers to recruiters on LinkedIn in the last year and a half. Like it's always the same, a young developer who is a year or so into their career and hitting their stride will get contacted out of the blue by a recruiter. Before too long they'll make an offer for a remote position that's comes with a pretty large pay increase and they expect an answer very quickly. These aren't companies I would consider competitors either, they're like some platform that gonna vaguely disrupt something or don't have a distinct product at all.

I always figured that places hiring this way would be lovely places to work. Turns out that one of the devs we lost this way has reached out about re-applying with us and they don't have nice things to say about their new company: Long hours, disorganized, high stress, high turnover, no direction. She disliked it enough that she's willing to take a pay cut to come back. People should be able to pursue whatever job opportunities they want, I'm at a loss about how to prevent this.

Switching jobs, especially that early in your career, comes with huge pay increases that most companies would balk at giving as a raise. Hiring developers cheaply straight out of university and trying to keep them near that pay grade as long as possible is a a common tactic; it's how most of the really big consultancy companies make their money. Staying more than two years in your first job is kind of sus if anything.

Even if you had a policy of giving pretty decent raises after every year spent, like 20% or something, it's not like the developers working under you have a guarantee that they will receive one, whereas having an offer in hand is concrete. I think the only way is to match the offer if a good worker approaches you with a genuine one. Of course, you might risk encouraging people to go looking for offers that way, but if this company is as good a place to work as you say, they will want to stay, compensation being equal.

thotsky fucked around with this message at 19:09 on Sep 22, 2022

thotsky
Jun 7, 2005

hot to trot
As long as we are forced to use Teams I don't see that it's worth it to introduce Slack. Teams is nothing like IRC, and really clunky, but one can just about make it work.

thotsky
Jun 7, 2005

hot to trot
Suckers, I never even joined.

thotsky
Jun 7, 2005

hot to trot
If you're doing cloud hosting or you are really small going with like Azure Monitor / Application Insights or whatever might be a lot simpler than setting up ELK + Prometheus/Grafana, but the latter will give you lots of transferable skills.

thotsky
Jun 7, 2005

hot to trot
I am proud that my thread title has stood the test of time, but


quote:

Working in Development: Let me show you how logic is never wrong

thotsky
Jun 7, 2005

hot to trot
Got a meeting with the CEO next week because "this Chat-GBT thing is big, how can you help us be the first to deliver it to Norway" :stare:

thotsky
Jun 7, 2005

hot to trot
As far as I know that poo poo is proprietary and they don't allow self-hosting so not sure what the guy wants.

thotsky
Jun 7, 2005

hot to trot
Clean code as a phenomenon is more destructive than the book itself. A lot of teams will treat it as a Bible, even though a bunch of stuff in it is obviously bad or outdated advice.

Developers who worry a bunch about "magic numbers" and breaking every logical block of code out into its own function rather than think critically about readability are the bane of my existence.

thotsky
Jun 7, 2005

hot to trot

Mega Comrade posted:

I never meet these developers. Instead I get the ones who see a 100 line function and go "well making it 120 lines won't hurt"

It might not. I don't mind a deep function. I do mind putting those extra 20 lines in another few lines of function boilerplate somewhere else, when it is only going to be called from that original function anyway.

thotsky
Jun 7, 2005

hot to trot

smackfu posted:

It would be great if college programming courses just had people submit PRs and then the professors commented on them and the students had to respond and fix their stuff.

I assume this is nothing like what is actually done even now.

(When I went to school, we had to email programs to the professor and I guess they just ran them? It was ancient times.)

The dude whose book is often recommended as an alternative to Clean Code (although the book is not really a close equivalent) does exactly that, and talks about it in this talk:

https://youtu.be/bmSAYlu0NcY

thotsky
Jun 7, 2005

hot to trot
I have definitely read worse.

thotsky
Jun 7, 2005

hot to trot
I used ChatGPT recently for navigating the incredible annoyance that is date handling in Java. It did good.

thotsky
Jun 7, 2005

hot to trot
Oof, I was laid off/made redundant/put on forced leave or whatever. I get a month of salary and then I have to go on the dole.

thotsky
Jun 7, 2005

hot to trot
The company I started at had no real experience doing IT consulting. They were a business consulting company who saw everyone else making money hand over fist, brought on some partners from the tech world of varying competency, and then made a bunch of bad hiring decisions.

Their big venture projects fell through, and they didn't have the connections or motivation neccesary to sell their tech consultants the old fashioned way. The few good devs were poached early. I only stayed as long as I did because I absolutely hosed them during salary negotiations and didn't really suffer much for not having anything to do.

thotsky
Jun 7, 2005

hot to trot
Got two offers, one from the biggest consultancy company here and one from a smaller one specializing in senior devs that has a flat, open and quite lucrative compensation scheme based on billable hours. If I go with the latter my TC will be about unchanged, whereas the former is probably not going to want to match that but has a higher guaranteed pay even if I am not on a project.

thotsky
Jun 7, 2005

hot to trot

Nothing much, what's TC with you?

thotsky
Jun 7, 2005

hot to trot

New Yorp New Yorp posted:

I've been a consultant for 11 years. The latter's pay scheme is going to gently caress you over hard in one way or another.

In a given week, I am billable 75% of the time if I'm lucky. Internal work, pre-sales and scoping new projects, etc eats up a tremendous amount of time.

This means one of two things:
1) You work 50-60 (or more!) hours a week to be billable for 40 hours.
2) You don't get paid anywhere near what you think you're going to get paid.

Some consulting companies will make part of your job performance billable hours, so scenario #1 is effectively mandatory. My company thankfully has no such policy. If I'm only billable for a third of the week because internal poo poo eats up all my time, I shrug and say "don't make me do so much non-billable poo poo and I'll bill more, okay it's Friday at 5 pm, talk to you on Monday"

I mean, with my last employer I was allocated like 5% because they were incompetent, but apparently consultants in this company don't really work with internal stuff or scoping much, and never sales. You're sold into a team and spend at least a year and sometimes multiple years there. It's possible to be unlucky though, I guess.

I have a friend who works there, and he's been allocated 100% for three years now.

thotsky fucked around with this message at 09:20 on Mar 17, 2023

thotsky
Jun 7, 2005

hot to trot
Started my first project as a consultant after joining the new company. Fired from project after two days!

The client signed me on kind of sight unseen, trusting the judgment of the team lead, but then decided they wanted to test the new hiring process they were developing for future internal hires on me after the fact. They wanted me to recite a bunch of orthodox OOP theory, principles, and patterns from memory. It's not my strong suit. Never got to see or solve any problems. They also wanted me to have a bunch of experience with ASP.NET webforms, a legacy framework not supported by ASP.NET Core, which is where my little .NET experience (I have mainly worked with Java) lies.

I am kind of relieved. I was pitched on them wanting someone to help them modernize an old .NET thing by rewriting it as Kotlin microservices and getting some DevOps stuff in. In reality, they just want someone to maintain this hulking monolith, and they are bound by contracts that preclude any kind of CD.

thotsky
Jun 7, 2005

hot to trot
There's also a huge amount of well-payed managers who have a vested interest in maintaining the status quo. With no people in the office it becomes that much more obvious that most of them hardly do anything.

thotsky
Jun 7, 2005

hot to trot
At a minimum, in orthodox Kanban there's also a ton of metrics you're supposed to track and use to tweak the process. There's plenty of meetings that are semi-analagous to Scrum meetings too.



A lot of teams who say they use Kanban just mean they have a board and don't want to be bothered with a lot of agile stuff beyond that, which is fine.

thotsky fucked around with this message at 20:38 on Jun 7, 2023

thotsky
Jun 7, 2005

hot to trot

steckles posted:

[*]The query that is being run seven times per minute or whatever is essentially asking for an entire database's worth of data
[*]Whichever contractor wrote the query says we make lovely, slow software and there's no possible way the use case could support a query that just asked the changes since the last API request, or used pagination for that matter
[*]On wasting a developer's time to assist them, it's determined that their request is used to compute some boring average over the last month's/week's/day's data and definitely didn't need stuff going back to 2016

You want to avoid the situation where the users decide the only way to get what they want is to mirror your entire database. If they do you will just end up with a series of daily/weekly queries asking for all your data, and end up with the blame for any data inconsistencies anyway.

Try to design your API to support what they want to do, and not support the sort of use you don't want to see?

thotsky
Jun 7, 2005

hot to trot
No way I would ever watch that video unless a boss told me to do it and I gained something material for doing so.

thotsky
Jun 7, 2005

hot to trot
Getting a raise before you've put in a year is basically impossible unless that was one of the terms of your employment.

thotsky fucked around with this message at 08:15 on Jun 28, 2023

thotsky
Jun 7, 2005

hot to trot

Bongo Bill posted:

Don't attempt feature parity with the old version. You are building a new product for the same market, so you still want to just target "minimum viable"

Feature parity is by definition the minimum viable for any rewrite (for most stakeholders).

I agree with you, but lol.

thotsky fucked around with this message at 10:48 on Jun 29, 2023

thotsky
Jun 7, 2005

hot to trot
I would prefer to design the app, tell someone else to code it, review their code and then fix all the devops poo poo myself. I get bogged down in everything being "perfect" when coding so it just takes way too long.

thotsky
Jun 7, 2005

hot to trot

prom candy posted:

Anyone got any thoughts on trunk based development? Hot? Or not?

It's the way to do it. I don't see why anyone would go with gitflow over trunk-based with short lived feature branches, it's a no-brainer upgrade in a world where CI/CD exists.

thotsky
Jun 7, 2005

hot to trot

Love Stole the Day posted:

Because in a Large Organization, the expectations of upstream/downstream teams will have many small adjustments as the overall Product feature is being developed, the managers want to save money on the development environment, decades of tech debt and painful Major Incidents prevent you from having any CICD at all, and deployment as a process takes an entire day because of knowledge silos even for the components that your team owns due to lack of documentation and knowledge transfer as people leave the company and go elsewhere.

That said, I currently work somewhere where releases involve literal paperwork and week long freezes.

thotsky
Jun 7, 2005

hot to trot

Falcon2001 posted:

Edit: Actually, wait, maybe I haven't done trunk based dev, typically I work on a task on my own for a couple days or whatever, handling it locally, and then merge directly to mainline. https://trunkbaseddevelopment.com/ seems to indicate that everyone commit at least once every 24 hours to mainline, which seems...bizarre, compared to just committing something as a solid coherent piece of code.

The point is not to have a time limit on your commit, or scheduled commits or anything. They're just pointing out that the branch is meant to be short lived and limited in scope. It's not a total disaster if you leave for the day without merging your branch, but ideally you will merge multiple times during a workday. Like, the nightmare scenario is the person who spends three weeks working on some refactoring and then sends you a pull request touching 150 files.

thotsky
Jun 7, 2005

hot to trot

Carbon dioxide posted:

Like, following that practice, if I'm refactoring existing code, and at the end of day I did about half of the work, which now causes the code to no longer compile because some of the function calls don't match the function signatures anymore, am I supposed to make a PR with both the original code, and an incompletely refactored copy of the code that is commented out so that the compiler doesn't complain? And where the reviewer can't make sense of my design because it's not complete yet?

That sounds stupid to me.

No, of course not. The argument is that if it takes multiple days to complete the task you're working on, it should ideally be broken down into smaller tasks that can be merged atomically. One of the solutions proscribed for developing features where this is not possible is to use feature flags.

thotsky fucked around with this message at 07:20 on Jul 10, 2023

thotsky
Jun 7, 2005

hot to trot

Xarn posted:

We just use the "no stupid bullshit" model. Development happens against main, releases are made as tags (and if hotfixes are needed, branches) on main when we decide to cut one, to merge your code you open up a PR that needs human review + automatic checks to pass. PRs are open as some reasonable amount of work is done.

That's not incompatible with what I was saying, it's just that "some reasonable amount of work" is more often measured in hours rather than days.

thotsky
Jun 7, 2005

hot to trot

Lyesh posted:

also the attitude that a bunch of current best practices aren't going to end up being considered "dumb poo poo that we did five years ago because we didn't know better"

or on a longer-term scale how stuff like OOP was considered the wave of the future for years and years. yet now there are places where inheritance is a swear-word.

I just know I prefer it to what I was doing before, but if something better comes along I will use that.

thotsky
Jun 7, 2005

hot to trot

Falcon2001 posted:

A recent series of meetings has me wondering if my current team is even a sane place to stay in the near future, and now I realize I don't have a lot of idea what other options I can look into.

I'm currently a python dev (I've done some C# but not professionally) and I've been recently promoted at a FAANG and I'm one of the stronger devs on my team. My background is in incident management work, which has a lot of useful overlap with any sort of production service supporting team in terms of 'how do you get poo poo done in enterprise'. I haven't got any frontend experience unfortunately, but I've done a lot of infrastructure management work in one way or another (both programmatic and just general sysadmin stuff historically).

What sort of job titles should I be looking for? I haven't actually had to job hunt as a dev yet, managed to get my current and previous gigs through industry contacts (and obviously I'll start talking to them again too). SRE seems promising as a general sort of 'must write code but understand uptime' sort of deal, but I'm trying to avoid getting back into massive oncall again after a decade of waking up at 3am.

Devops would work.

thotsky
Jun 7, 2005

hot to trot
I generally go "Oh, you could obviously use the reverse() function of StringBuilder, but I'll write it out" because if I don't it's a goddamn guarantee that their second question is going to be "what if you couldn't use any built in functions?".

thotsky
Jun 7, 2005

hot to trot
Seems unlikely they will acknowledge this work if that means acknowledging they dropped the ball earlier. Also, this new guy has already got the recognition, at best you can hope for another pat on the head. I would focus on what you can add to the process. Like, just present your old stuff again if there's stuff there that this guy didn't cover. You can mention it's old news as a dig for your own satisfaction, but presenting it as new might make you seem quick and clued in.

If he's already covered everything I think you're poo poo out of luck.

thotsky
Jun 7, 2005

hot to trot

Falcon2001 posted:

When I started working in tech I got mad because 'Ping' was used to mean 'message someone' when one of the most important parts of pinging is that it contains a positive confirmation of receipt, whereas messaging is a one way communication with no acknowledgment.

I got over it eventually, but that was my weird thing I got mad about.

syn sounds like a stripper name tho

thotsky
Jun 7, 2005

hot to trot

downout posted:

One of our teams has a bunch of engineers that always ask “please approve this PR!”

Why yes their code reviews are box checking dogshit, why do you ask?

It’s a pretty obvious tell that their entire team culture around code review is terrible.

I have never been on a team with opt-in (ie: no tech lead with sole responsibility for) code reviews where you didn't have to assign, notify and otherwise bug people into actually doing them.

thotsky
Jun 7, 2005

hot to trot

Xarn posted:

Tech lead with sole responsibility for reviews sounds ghastly. And assigning/notifying people is normal, do you expect everyone to just look at all open PRs at all times to write notes? How do they know that the PR is ready? How do they know the PR should interest them?

I vastly prefer having a tech lead with the sole, or at least primary responsibility for performing code reviews. Otherwise it just takes too long to get them done. Developers who have tickets of their own are not going to drop whatever they're doing to review mine, and ideally I want to have several PRs go through in a single workday.

I have worked at places where code reviews were meant to be handled communally by people checking the open PR page whenever they were not working on something, which resulted in them never getting done. I agree that bugging people about PRs is the norm; downout is the dude who seems to think that's weird.

Also, you don't post PRs before they're ready. If you absolutely have to (horrible, means it's a branch that's definitely living too long or that what you really want to do is a bit of pair programming) you mark them with WIP.

thotsky fucked around with this message at 22:23 on Oct 7, 2023

thotsky
Jun 7, 2005

hot to trot

Steve French posted:

I feel like this misses some huge benefits of code review: it doesn’t just make the code better, it’s a knowledge sharing tool. People learn from having their code reviewed, even if it’s not by someone more experienced (“ah I guess this pattern is confusing to less experienced people”), and even if they’re the one reviewing the code (reading code in general is educational and makes you better at writing it, as does asking clarifying questions and getting answers when something doesn’t make sense).

I think all of that still happens to a reasonable degree even when you have a person on the team with the primary responsibility for performing code reviews. It can be a back and forth, and sometimes the tech lead needs stuff reviewed too. That said, I also don't buy into the criticality of involving the entire team in backlog refinement, planning poker and stuff like that so I might just favor more hierarchy in teams than you and Blinkz0rz.

Adbot
ADBOT LOVES YOU

thotsky
Jun 7, 2005

hot to trot
You expect upper management to take your side over the VP? Sounds like the dude asked a dumb question and you overreacted. People in management tend to ask a lot of dumb questions, and don't take too kindly to being met with insubordination. What are you hoping to achieve by escalating? What is your plan B if it backfires?

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply