IT/Software career thread: Invert binary trees for dollars.
- Thread starter Traak
- Start date
-
Guest, it's time once again for the massively important and exciting FoH Asshat Tournament!
Go here and give us your nominations!Who's been the biggest Asshat in the last year? Give us your worst ones!
Noodleface
A Mod Real Quick
- 38,377
- 16,298
alavaz
Trakanon Raider
- 2,003
- 714
I've got a couple of potential jobs I'm pursuing. Id like to get the one I mentioned previously, but I'm also interviewing with Microsoft after the holiday. The first couple of phone interviews went well and they really need cleared people. Will be supporting all gov agencies and like 80% travel but pay is damn good.
I actually really enjoy my present job though. Working with the SOF community is very interesting and a lot less bogged down than big army/defense. I know I can make a lot more money though and hate knowing that I'm leaving a lot on the table by staying where I'm at.
I actually really enjoy my present job though. Working with the SOF community is very interesting and a lot less bogged down than big army/defense. I know I can make a lot more money though and hate knowing that I'm leaving a lot on the table by staying where I'm at.
Namon
Blackwing Lair Raider
- 1,976
- 2,565
I'm nowhere near the same league as pretty much all of you, I am just a network admin who babysits servers and fixes end user crap. Well we had a tornado knock the power out for a few hours on Saturday night, and in the craziness (wife's family farm and their houses got hit), I totally forgot that the power was off longer than the battery had time for, and had to frantically go in and get all the hosts and the NAS revived and back up and running. Ugh I forgot to place some coal between my cheeks while they were clinched so tight. I'd have been a millionaire, but at least everything is back up and humming now.
- 1
- 1
- 7,879
- 507
I'm sure the old tech and red-tape are especially bad in Defense, but a lot of large enterprises are shit-tier when it comes to getting rid of tech debt.
Noodleface
A Mod Real Quick
- 38,377
- 16,298
The only way to escape red tape is to work at a startup that is currently not making any money so they don't care if the stack falls over. Every profitable company (bonus points if public) will have layers and layers of red tape to do anything.
- 16,967
- 7,988
Spurred by a mini tangent in the Hearthstone thread, I have a question for the devs of this thread, or I guess anyone that writes codes somewhat seriously. What would your reaction be to QA telling you to review your own damn test results?
Obviously I phrased that bombastically. I would never approach this matter that way but I do feel like that often. I was hired as QA engineer, partly to review test results, and partly test system maintenance and improvement(time for this last part rarely ever happens). I'm cognizant enough to realize that the least efficient person to review test results is someone that spends little to no time in the code base that caused the bug. In this classic dev-QA dichotomy, that's exactly what the QA person is. Am I wrong to want to fix this inefficiency?
Regardless of how it's done, would the devs of this thread want to review their test results? And I do mean their, as in with relative certainty, the test failures were caused by your code changes. I've floated this idea by my manager, the product architect, and another colleague and it's been basically been met with "meh" or feigned interest so they'll shut me up.
I will admit some of this is selfish. Reviewing test results is fucking boring. But idk, maybe the disinterest stems from no direct stakes(none of my code caused these failures) and that the system is already broken. We have one person who's sole job is to review test results. As in, he can't do anymore, so no more new tests. And on heavy weeks, it's easily 50% of my time. Seems like a waste of human labor.
That aside, even the time and accounting benefits seems like it would be worth it. Having devs review test results on a per commit basis will get a more accurate accounting of the true cost of feature development. Currently, QA's review time goes into a bottomless bucket that's attached to no feature or bug.
I even have a catch phrase: QA's job should be to help you review your test results, not review them for you. I've already imagined how I would used it in conversation, so that means it will never happen
Please be honest. If I'm completely wrong, I'd like to know sooner before stubbornly try to bring this up 3+ more times. I'm still quite new to the pure software development world(mainly worked QA in hardware), maybe this is just how shit is.
Obviously I phrased that bombastically. I would never approach this matter that way but I do feel like that often. I was hired as QA engineer, partly to review test results, and partly test system maintenance and improvement(time for this last part rarely ever happens). I'm cognizant enough to realize that the least efficient person to review test results is someone that spends little to no time in the code base that caused the bug. In this classic dev-QA dichotomy, that's exactly what the QA person is. Am I wrong to want to fix this inefficiency?
Regardless of how it's done, would the devs of this thread want to review their test results? And I do mean their, as in with relative certainty, the test failures were caused by your code changes. I've floated this idea by my manager, the product architect, and another colleague and it's been basically been met with "meh" or feigned interest so they'll shut me up.
I will admit some of this is selfish. Reviewing test results is fucking boring. But idk, maybe the disinterest stems from no direct stakes(none of my code caused these failures) and that the system is already broken. We have one person who's sole job is to review test results. As in, he can't do anymore, so no more new tests. And on heavy weeks, it's easily 50% of my time. Seems like a waste of human labor.
That aside, even the time and accounting benefits seems like it would be worth it. Having devs review test results on a per commit basis will get a more accurate accounting of the true cost of feature development. Currently, QA's review time goes into a bottomless bucket that's attached to no feature or bug.
I even have a catch phrase: QA's job should be to help you review your test results, not review them for you. I've already imagined how I would used it in conversation, so that means it will never happen
Please be honest. If I'm completely wrong, I'd like to know sooner before stubbornly try to bring this up 3+ more times. I'm still quite new to the pure software development world(mainly worked QA in hardware), maybe this is just how shit is.
- 2,010
- 3,964
Deathwing
I wrote up a big reply, but re-reading your post it wasn't quite what you asked.It's not that developers don't want to review the output of the tests ran against their code. Instead, it's usually that development deadlines are so tight that they don't have time to do that kind of thing.
I would instead suggest that you don't have anyone examining the output of the tests. Use a computer - that's what they are for. When code is checked into certain branches it should kick off automated tests which will notify the person who checked in the code of the problems. Work on implementing that kind of system along with a way to keep on top of adding new tests as the product evolves. Setting up and expanding systems like that are roughly an infinite amount of work. The results are usually measurable, too, so it looks good for you long term.
Get the ball rolling with open source tools. Jenkins + your test framework of choice.
Lendarios
Trump's Staff
- 19,360
- -17,424
Spurred by a mini tangent in the Hearthstone thread, I have a question for the devs of this thread, or I guess anyone that writes codes somewhat seriously. What would your reaction be to QA telling you to review your own damn test results?
Obviously I phrased that bombastically. I would never approach this matter that way but I do feel like that often. I was hired as QA engineer, partly to review test results, and partly test system maintenance and improvement(time for this last part rarely ever happens). I'm cognizant enough to realize that the least efficient person to review test results is someone that spends little to no time in the code base that caused the bug. In this classic dev-QA dichotomy, that's exactly what the QA person is. Am I wrong to want to fix this inefficiency?
Regardless of how it's done, would the devs of this thread want to review their test results? And I do mean their, as in with relative certainty, the test failures were caused by your code changes. I've floated this idea by my manager, the product architect, and another colleague and it's been basically been met with "meh" or feigned interest so they'll shut me up.
I will admit some of this is selfish. Reviewing test results is fucking boring. But idk, maybe the disinterest stems from no direct stakes(none of my code caused these failures) and that the system is already broken. We have one person who's sole job is to review test results. As in, he can't do anymore, so no more new tests. And on heavy weeks, it's easily 50% of my time. Seems like a waste of human labor.
That aside, even the time and accounting benefits seems like it would be worth it. Having devs review test results on a per commit basis will get a more accurate accounting of the true cost of feature development. Currently, QA's review time goes into a bottomless bucket that's attached to no feature or bug.
I even have a catch phrase: QA's job should be to help you review your test results, not review them for you. I've already imagined how I would used it in conversation, so that means it will never happen
Please be honest. If I'm completely wrong, I'd like to know sooner before stubbornly try to bring this up 3+ more times. I'm still quite new to the pure software development world(mainly worked QA in hardware), maybe this is just how shit is.
Oh boy where do I begin.
First, as a developer, there are plenty of valid scenarios where the bug is fixed locally( as in my machine, with a relatively new ), but once it gets deployed to a more updated environment, it affects other things, or is not really fixed.
I also don't do recursion testing locally, I fix(hopefully) exactly(hopefully) what the bug says, and plenty of time I miss the interactions of other areas.
For example, I don't remember/forget that there are multiple places for data entry, and me fixing the bug of "whitespace at the end of a name" on screen 1, I forget/don't know that there are another screens where the input should be sanitized.
Also I tend to program on a one way track, I tend to use the same dataset to test, often with as little key strokes as possible. First Name: FN; Last Name: LN; etc. This is not ideal for real world testing scenarios.
Lastly human nature. There is a reason why supervisors exists. It is to make sure human do the shit they are supposed to do. Sometimes developers get lazy and don't cross all their eyes and t's. QA are sort of developer's supervisors.
Lendarios
Trump's Staff
- 19,360
- -17,424
The problem with Unit testing, is that the time it takes to do and maintain is never properly scheduled, and rarely done at all.
Even when I'm deploying with salesforce which requires a 75% code coverage to even deploy on the server, i just create a test that runs everything and never asserts anything.
Even when I'm deploying with salesforce which requires a 75% code coverage to even deploy on the server, i just create a test that runs everything and never asserts anything.
I can't speak for Team5 and how they do their QA since I haven't really worked with them a whole ton but I can go over how we do QA here on battle.net purchasing.
First, and pretty obvious, all your work you do is attached to some sort of story/bug in jira. Though not required for the most part you create a branch for each story in jira unless you're doing very greenfield development work. You branch off master and implement your changes. I then build my stack locally and do a very brief test to make sure the main-line case works. We then have a central CI location for integration testing and first-pass QA testing. The CI environment is ok but not perfect since it can get out of date with what master really is because sometimes people put experimental shit in there that never goes to master. But it works out fairly well.
At this point I drag my story over to ready for QA. Here on BNet we have embedded QA staff. This isn't always the case for game teams. But we have our "QA guys" who sit in the bullpen with us in case they need to ask questions and get clarity. This is pretty important. It is required that developers and QA have a symbiotic relationship. I know QA isn't out to get me and QA knows I'm trying to give them quality code. We're all in this together trying to put out the highest quality product we can put out. So anyways at this point QA does a more rigorous test of various edge cases and scenarios. This isn't really engineering's job to do this. As an engineer I'm expected to write features and fix bugs. If you expect the engineers to spend half a day doing QA work that engineer should be paid less. I want very easy to understand reproducible steps. I am a smart guy so I don't need QA to belabor me with results just let me know the expected behavior and the failing behavior and how to do it. I'll work it out from there.
In the CI environment is where most bugs are found. Bugs with the story get attached and priority is assigned. Sometimes bugs are fine to go live with but other times not. In general QA has the final say if a story can go live or not. I'll fix and implement the bugs, smoke test, put into CI and re-assign back to QA. Once everything has passed I then go into the release pipeline. We deploy for the most part weekly here. I'd estimate maybe 45 planned deploys a year or so. I merge all my branches into the release branches and then QA tests once again in the release environment. For the most part everything passes here but it is important to release test again since this is the candidate for production. Once QA has given the go-ahead for the deploy we are ready to go to prod.
This is all the manual process. We also have automation engineers that generally do in-project automation against the CI environment.
First, and pretty obvious, all your work you do is attached to some sort of story/bug in jira. Though not required for the most part you create a branch for each story in jira unless you're doing very greenfield development work. You branch off master and implement your changes. I then build my stack locally and do a very brief test to make sure the main-line case works. We then have a central CI location for integration testing and first-pass QA testing. The CI environment is ok but not perfect since it can get out of date with what master really is because sometimes people put experimental shit in there that never goes to master. But it works out fairly well.
At this point I drag my story over to ready for QA. Here on BNet we have embedded QA staff. This isn't always the case for game teams. But we have our "QA guys" who sit in the bullpen with us in case they need to ask questions and get clarity. This is pretty important. It is required that developers and QA have a symbiotic relationship. I know QA isn't out to get me and QA knows I'm trying to give them quality code. We're all in this together trying to put out the highest quality product we can put out. So anyways at this point QA does a more rigorous test of various edge cases and scenarios. This isn't really engineering's job to do this. As an engineer I'm expected to write features and fix bugs. If you expect the engineers to spend half a day doing QA work that engineer should be paid less. I want very easy to understand reproducible steps. I am a smart guy so I don't need QA to belabor me with results just let me know the expected behavior and the failing behavior and how to do it. I'll work it out from there.
In the CI environment is where most bugs are found. Bugs with the story get attached and priority is assigned. Sometimes bugs are fine to go live with but other times not. In general QA has the final say if a story can go live or not. I'll fix and implement the bugs, smoke test, put into CI and re-assign back to QA. Once everything has passed I then go into the release pipeline. We deploy for the most part weekly here. I'd estimate maybe 45 planned deploys a year or so. I merge all my branches into the release branches and then QA tests once again in the release environment. For the most part everything passes here but it is important to release test again since this is the candidate for production. Once QA has given the go-ahead for the deploy we are ready to go to prod.
This is all the manual process. We also have automation engineers that generally do in-project automation against the CI environment.
- 2
- 2,010
- 3,964
Yes, you don't, but don't you think there is value in a person/position that would flesh out those tests? I guess it depends on the product.
Lendarios
Trump's Staff
- 19,360
- -17,424
I'm not saying there is no value. I'm saying there is little time for it.
Also depends on how critical is the item u are working on. Sections of code dealing with critical data you try to look at them more carefully. If is a form where you just input a, b and c, then it gets less reviewed.
- 2,010
- 3,964
Yes, at a large company there would be a position that is just that. What I was (poorly) trying to say is that it's not really the best idea to have the feature developer perform this task.
At a smaller company I imagine the role would be to set up and run the automated testing infrastructure, shore up the tests, and be in charge of deploying to test / staging / production. I think that's a valid role.
- 2,010
- 3,964
My personal experiences kind of fuck with my point of view when it comes to this kind of stuff. I work at two places which are polar opposites. One is a tiny place where I have worked with a handful of people for 15 years. The other makes clinical trials software. I have to deal with crazy restrictions and no restrictions with a nap in between each day. I'm trying to rough out what the middle ground would look like for most companies.
A smaller company probably doesn't care. If you're a small place who's product is software you are probably just looking to expand your stack as rapidly as possible, get bought out and then dump your house of cards on whatever schmuck made your founders rich.
But yes writing unit tests should be baked into the time assessment on an individual level. Lend is also right where in the real world you don't really need to write unit tests for everything. Especially things which don't have a ton of branching logic paths.
But yes writing unit tests should be baked into the time assessment on an individual level. Lend is also right where in the real world you don't really need to write unit tests for everything. Especially things which don't have a ton of branching logic paths.
- 1