IT/Software career thread: Invert binary trees for dollars.

I get a huge glare on my main monitor from the sun so unless you sit at my angle you can't see shit. Starcraft goes on the second monitor that you can see out from the hallway and can see clear as day. Because why not.

Deathwing_sl said:

Vinen, with the money you say you make, I'm willing to bet you still see people coming well before they can see your computer screen.

Click to expand...

Nope. Only people on the management track above a certain level have offices in our building. I just get to piss people off by talking loudly on the phone for 3-4 hours a day. Myself and the only other team member on the technical track at my level or above are stuck in cubes. That said, none of the offices have external facing windows sooo... :3

My desk faces a window but the screen is defiantly in view of a wide area. Bored and procrastinating updating a whitepaper I publish so here is a shit diagram. Each of these squares represent a two person cube. The walls are 3~ feet tall so it's not like they block a screen.

Good programming music IMHO is anything dark and ambient. Listen to a lot of these at work:

Solar Fields
Carbon Based Lifeforms
Stellardrone
Eve Online Soundtrack

For you guys that are on development teams -- how does your team enforce code styles? I guess I'm "one of those guys" that is extremely anal over variable and method names. But our team has no consistency at all -- these people are all over the place. I realize styles have changed over time and people just have their habits depending on how long they've been coding. But things like PascalCase for private variables I don't think was ever in vogue (talking Java/C# world here).

On my other team, I created a coding standard document with the team that everybody "agreed" on. Of course, team/tech lead or whoever is in charge will have to decide on a few things because the developers just like to argue about petty shits. The second step was mandatory code reviews before your code goes to QA.

In any case, that second step is critical for the success of your code.

ShakyJake_sl said:

For you guys that are on development teams -- how does your team enforce code styles? I guess I'm "one of those guys" that is extremely anal over variable and method names. But our team has no consistency at all -- these people are all over the place. I realize styles have changed over time and people just have their habits depending on how long they've been coding. But things like PascalCase for private variables I don't think was ever in vogue (talking Java/C# world here).

Click to expand...

In java (other languages?) there is something called a checkstyle document that you can enforce. It does things like capitalization and method names and shit like that. Personally I hate it. It feels like it screams the team lead thinks everyone is too fucking stupid not to put underscores in method names.

You can even make it so the build fails if the checkstyle fails then it'll alert of the user that did the failing check-in. Again I find it to be a fucker move.

Citz_sl said:

The second step was mandatory code reviews before your code goes to QA.

Click to expand...

Speaking of code reviews, this is how we do it: developer finishes task, sends an email out saying, "hey need someone to review my code." Random available person picks it up, looks over it briefly and gives a "thumbs up" 99% of the time. I don't think I've ever had someone question why I'm doing something a certain way, made recommendations, or anything of that sort.

My previous job was coding scripts and in that department we had "code review Tuesday" where the entire group examines the code on a widescreen projector. I really liked that approach as it allowed for others to learn and makes it a bit less of a chance of feeling attacked by a single individual.

Tenks_sl said:

In java (other languages?) there is something called a checkstyle document that you can enforce. It does things like capitalization and method names and shit like that. Personally I hate it.

Click to expand...

StyleCop is one I've considered recommending.

It feels like it screams the team lead thinks everyone is too fucking stupid not to put underscores in method names.

Click to expand...

Ironically, code checked in today had public method names with underscores and all lower case. Bizarre shit.

ShakyJake_sl said:

Speaking of code reviews, this is how we do it: developer finishes task, sends an email out saying, "hey need someone to review my code." Random available person picks it up, looks over it briefly and gives a "thumbs up" 99% of the time. I don't think I've ever had someone question why I'm doing something a certain way, made recommendations, or anything of that sort.

Click to expand...

We used to work that way and that's the exact reason why we changed the process. Now, only two seniors that actually give a shit can do a code review.

ShakyJake_sl said:

Speaking of code reviews, this is how we do it: developer finishes task, sends an email out saying, "hey need someone to review my code." Random available person picks it up, looks over it briefly and gives a "thumbs up" 99% of the time. I don't think I've ever had someone question why I'm doing something a certain way, made recommendations, or anything of that sort.

My previous job was coding scripts and in that department we had "code review Tuesday" where the entire group examines the code on a widescreen projector. I really liked that approach as it allowed for others to learn and makes it a bit less of a chance of feeling attacked by a single individual.

Click to expand...

We used Crucible to do our code reviews. Though we really only reviewed major check ins by people generally new to the team.

Citz_sl said:

We used to work that way and that's the exact reason why we changed the process. Now, only two seniors that actually give a shit can do a code review.

Click to expand...

hah same thing as my company. The shit that gets green lit if the person doesn't care who's doing the review can be pretty scary and we've been burned pretty badly on it. We have a coding standard document, though we tend to leave code reviews to the end of the feature before we hit QA so if there are big changes that need to happen to meet the standard it'll sometimes get passed anyways. Since we work in C++ refactoring code from libraries used across multiple projects can be kind of a pain in the ass, so it's sometimes safer/less risk to just leave it as is.

I'm curious for people who do the group reviews with a projector how long that takes? I spend 3-5 hours a week doing reviews, and I can't imagine how much longer that would take doing it via committee. Not to say that I don't see the advantage of it.

Yeah the team I was on previously would have done really well with actual code reviews. The shame is it was an enormous pile of C so very few people knew how to work with it. For the most part any bug fixes are simply adding an if test for the very, very specific case that caused the bug, telling the person who ran into the bug to try it again and they're happy because it works but the fix was such a one-off band-aid that it constantly runs into needing these one-off fixes instead of addressing the root cause of the problem. Even more hilarious the team lead would yell and scream if you didn't "fix" the bug in like 4 hours because you were trying to address the underlying problem. So I left the team.

ShakyJake_sl said:

For you guys that are on development teams -- how does your team enforce code styles? I guess I'm "one of those guys" that is extremely anal over variable and method names. But our team has no consistency at all -- these people are all over the place. I realize styles have changed over time and people just have their habits depending on how long they've been coding. But things like PascalCase for private variables I don't think was ever in vogue (talking Java/C# world here).

Click to expand...

I work on a 10 person BIOS team that also consists of a US team and Shanghai team. We aren'ttooanal about code styles, but I find most people seem to adhere to an almost identical style. We have some rules like making local variables AllFirstWordsAreCaps and all global variables are gVarName. The only person who doesn't seem to follow any style at all is the co-op we have, he seems to mix and match and do whatever he wants. We do pull requests as code reviews, so if anything sticks out we bring it up. Only need one person to approve a code review though, so if someone approves shitty code then there it is.

Tenks_sl said:

Yeah the team I was on previously would have done really well with actual code reviews. The shame is it was an enormous pile of C so very few people knew how to work with it. For the most part any bug fixes are simply adding an if test for the very, very specific case that caused the bug, telling the person who ran into the bug to try it again and they're happy because it works but the fix was such a one-off band-aid that it constantly runs into needing these one-off fixes instead of addressing the root cause of the problem. Even more hilarious the team lead would yell and scream if you didn't "fix" the bug in like 4 hours because you were trying to address the underlying problem. So I left the team.

Click to expand...

That sounds toxic, as a general rule we find out the root cause of the issue and then leverage whether a quick fix is better or fixing the underlying issue. Even if we do the quick fix, we schedule an overhaul in a future build. Since migrating to our new product from old one, we've been following that pattern and it's kept the code very clean and manageable. We have very few problems considering we don't run any automated tests against our code (yea it's fucking retarded but not my call).