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

Celestein_sl said:

They've yet to C why they need the D. Everyone needs the D.

But really, C is probably not going to go anywhere in our lifetimes because the truth is that for x86 architecture C is basically it in terms of performance. C was so well designed out that gate that there's no reason to use anything else if you're looking for raw performance, you can add more features, but in terms of hypothetical speed you can't make anything significantly better than C(it's possible, but we're talking low single digit differences here). So the community as a whole sees no real reason to re-invent the wheel, when they do, we get things like D, Rust, etc, which claim to be very fast with essentially just more features or different paradigms, but they're still essentially C.

I expect this to change once X86 architecture starts dying in the next 15yrs~, because C is not optimal for ARM assembly, and I predict that either ARM will over-take x86 in the future or Quantum computing will make this all pointless. Whichever gets there first!

Click to expand...

I wonder about whether I will always be in the business of Legacy development, spend a lot of time looking at different languages, new stuff, functional et al. Messed with Go for a minute, always seems to circle back to some coversation on C. COBOL and C are pretty similar anyway. The question in my mind is always When will the Mainframe be replaced? Am I limiting my skill set by staying with it, having not used OOP style languages much, am I slowly structuring my brain in such away that it will be difficult to adapt to newer stuff I have to? How can I make myself a better developer, and more adaptable in lue of that? Should I focus on staying close to the metal with C like Noodle, or move onto Python/insert language.

These are more rhetorical questions, than anything.

It is my understanding that we can't get rid of mainframes and tape, it would cost too much. That's why we see VTEs (virtual tape emulators) showing up so that new technologies can interact with them. Have you considered looking into stuff like that? I think IBM has some stuff and I know EMC has Disk Library for Mainframe

Tuco_sl said:

Re: People asking questions ad infinidum: I think the best way to handle it is to become increasingly vague with the more questions that are asked.

"How do I convert to hex in java?"
"Integer.valueOf(String.valueOf(n), 16);"

ten minutes later...

"How do I convert to binary?"
"https://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html"

an hour later...

"How do I parse a number out of a string?"
"google.com"



However, depending on the situation some people get tasked with shit they shouldn't be doing in a field they know nothing about and care nothing about. If I'm tasked with a day long project of why my passwords aren't being salted right ( I know and care nothing about encryption etc), you're damn right I'm not going to go crack open a book on encryption to solve my problems. I'd rather lean heavily on the folks who should probably be doing the work in the first place but they fucked up somehow and now I'm involved. Obviously this isn't true in a lot of cases, and it reeks of entitlement but I think it's true.

Click to expand...

Right, I gave him the benefit of the doubt at first but now I'm vague. He confided in me that he's worried because he's worked in our group for a month and not submitted any code. He doesn't understand that our job is 90% debugging and 10% coding when you're new. People like me are adding new features but new people are working through our bug reports and addressing or fixing them.

I actually had a coworker come ask if I was getting bothered by it. I guess he overheard him asking me a million questions.

I've seen a few people doing it.. I can't talk to a duck at my desk.

lendarios_sl said:

lol so this is common..
Rubber duck debugging - Wikipedia, the free encyclopedia

Click to expand...

Yeah, there have been many times I've realized a solution while trying to explain it on a StackOverflow post. But I wouldn't literally place a rubber duck at my desk...

I've taken the time to write out a potential SO post in Notepad just to put my thoughts to paper, list out what I've tried and where things are failing. Every single time I think of a new way to approach the problem or words to look up a solution.

I find I usually struggle not with writing code, but moreso with implementing protocols or communicating with external stuff. I mean, C is only so hard..

Rubber Duck debugging is legit. It doesn't literally mean talk to a rubber duck about the problem. Try this next time. You think/know a coworker has the answer. Spend 30 minutes fumbling around in the code and getting an idea of how it works. Start writing an email to the guy. I guarantee you after the second sentence you'll start double checking the code. After the fifth you'll start to figure out the answer. By the end of the paragraph you'll hit "Discard" and you'll figure it out for yourself. I do it all the time. Bonus content is if it turns out you don't understand and don't realize the answer yourself you already have an email with your logical progression and thoughts already in an email to hit Send.

Usually what happens to me is I write the email to my boss with a long explanation of how I think it works and what parts aren't working and it's really detail oriented and then I hit send and immediately I know what the problem is.

My boss is good at the "please look here: somefile.c(735)"

I know only myself and CnCGod really care about the Hadoop ecosystem but we just moved over from CDH4.6 release of Cloudera distro over to CDH5.4. The big difference between the two is moving from MapReducev2 over to Yarn which means we can use Spark. We've had it up and running in our perf environment for about two weeks and I've already gotten a ticket that I decided I can do easily in Spark. It is similar-but-different to another MapReduce job we have that is easily over 600 LOC. It uses this homegrown idea of BigTable/LittleTable which is for merging a smaller dataset with a larger dataset (be it HBase, HDFS, etc) and Spark gets rid of having to do any of that stuff. So I managed to trim down a 600+ LOC MapReduce job down to a less than 100 LOC Spark job. Its such an amazing piece of tech I can see why so many people are on the Spark hype train.

Something else that has been bugging me lately is how other developers on my team will use the excuse "It's done like this elsewhere in the project" to justify poor coding or bad practices. Simple examples include concatenating strings (that aren't compile-time constants), catching an exception, do nothing with it then re-throwing it, and using non-generic collections (like C# ArrayList and HashTable) to name a few.

Also, most refuse to use newer technologies (which some really aren't that new here in 2015) that have been added to the framework. Our application is based on .NET WebForms, but there have been some nice additions in .NET such as fancier data controls, model-binding and validation. Does anyone use them? Nope. They continue to programmatically create, populate, and validate HTML controls in the code-behind. It's so ugly and hard to read.

And the reasoning is that "it's consistent with how the rest of the application is written." Does anyone else agree with this? To never advance your code in order to keep it consistent with how it was written 5, 10, or 15 years ago?

No! They should be doing it correct and refactoring anywhere they see it was done before at sub par standards. Continuing poor practices is lazy and dumb in the long run for maintinance.