Software Development and Programming Careers (Official Discussion Thread)

[Arishok]

Well considering I don't want to go into programming professionally (my goal is to own a gaming company or become a 3D artist) it seems like python is the way to go for me. I'll just hire programmers that can use those other languages.

 

[OCCAMS_RAZOR]

I remember one project (two weeks to do) was basically to emulate nix directory and file structure in c that was FRESHMAN year lol

I did that too, but that was in second year though. i'm not sure if that counts as freshman in the states.

the thing with moving from high-level to low-level is that it's not like programming itself becomes harder. the logic is still the same, but the tools you use become cumbersome. OOP has been a tremendous boon in the field because it aligns with most people's way of thinking. C is completely procedural. the control flow is fukked. the naming is fukked. everything is fukked. but that's if you've been babyed around with a high-level language.

dude, my first time dealing with pipes in C? shyt made no sense. i was upset because i knew what i wanted to do but i didn't know what C was doing low-level and hence the language was being unco-operative.

the thing is, how a computer works, isn't the same as how we'd like to think they work. the abstraction is good, because it makes shyt easy to wrap your head around, but what the more advanced programmers know is that, it's just that an abstraction, nothing more, nothing less.

smart dumb muhfukkas love to state that it all boils down to 1s and 0s. well, in a way they're right. we'd just prefer to pretend otherwise.

 

[yseJ]

I did that too, but that was in second year though. i'm not sure if that counts as freshman in the states.

the thing with moving from high-level to low-level is that it's not like programming itself becomes harder. the logic is still the same, but the tools you use become cumbersome. OOP has been a tremendous boon in the field because it aligns with most people's way of thinking. C is completely procedural. the control flow is fukked. the naming is fukked. everything is fukked. but that's if you've been babyed around with a high-level language.

dude, my first time dealing with pipes in C? shyt made no sense. i was upset because i knew what i wanted to do but i didn't know what C was doing low-level and hence the language was being unco-operative.

the thing is, how a computer works, isn't the same as how we'd like to think they work. the abstraction is good, because it makes shyt easy to wrap your head around, but what the more advanced programmers know is that, it's just that an abstraction, nothing more, nothing less.

smart dumb muhfukkas love to state that it all boils down to 1s and 0s. well, in a way they're right. we'd just prefer to pretend otherwise.

I agree abstraction is good in general, but smart abstraction at that. my main point is that knowledge of stuff underneath makes your high-level code that much better.

imo you cant just ignore the stuff underneath.

plus if youre a programmer you usually naturally WANT to understand how stuff works underneath. maybe not down all the way but in general.

a class on compilers is a huge eye-opener, for example, at least to me, even though its practicality is almost nonexistent nowadays- best compilers are so robust you'll never be writing your own compilers and you'll barely doing your own optimizations, even in C. even then, there are so many things that you can learn and make your code better, its crazy.... just by figuring out WHY certain things are that way makes you a better coder.

 

[yseJ]

also pipes ? pipes in C are pretty straightforward. where you were coming from where pipes were much easier ?
I mean, all unix is basically written in C, so any pipe you write in C is unix-like pipe

 

[OCCAMS_RAZOR]

also pipes ? pipes in C are pretty straightforward. where you were coming from where pipes were much easier ?
I mean, all unix is basically written in C, so any pipe you write in C is unix-like pipe

what was difficult initially for me is that i didn't understand the control flow. i didn't know that one thread will 'block' until input from another thread gets piped into it. i agree that it's pretty straightforward. it's just i came from a background where i expected everything to be intutive and to make sense instantly. my whole dealing with pipes was a watershed moment, as it made me realize that code doesn't necessarily need to cater to the lowest common denominator.

my academic career has been pretty topsy-turvy so i never got a chance to take a class on compilers but i wish i did sometimes. i remember one time in a theory class a lecturer kind of mentioned off-hand that every method call has a setUp() and tearDown() (likke when you're doing tests) & that we would learn more about this in compilers.

dawg, that statement had me with its profundity. i could never look at a 'getter' method and a 'setter' method the same again. up until now, i prefer to deal with naked variables than with setters and getters. i bet if i read up on compilers, my programming game would increase by a factor of 10.

 

[yseJ]

what was difficult initially for me is that i didn't understand the control flow. i didn't know that one thread will 'block' until input from another thread gets piped into it. i agree that it's pretty straightforward. it's just i came from a background where i expected everything to be intutive and to make sense instantly. my whole dealing with pipes was a watershed moment, as it made me realize that code doesn't necessarily need to cater to the lowest common denominator.

my academic career has been pretty topsy-turvy so i never got a chance to take a class on compilers but i wish i did sometimes. i remember one time in a theory class a lecturer kind of mentioned off-hand that every method call has a setUp() and tearDown() (likke when you're doing tests) & that we would learn more about this in compilers.

dawg, that statement had me with its profundity. i could never look at a 'getter' method and a 'setter' method the same again. up until now, i prefer to deal with naked variables than with setters and getters. i bet if i read up on compilers, my programming game would increase by a factor of 10.

theres always stuff that if you just do high-level you miss on, because it makes visibly no difference on high level yet it does on low level and you get drastically different results. shyt like that is really obvious when you start going in depth on compilers

for example, http://stackoverflow.com/questions/...rted-array-faster-than-an-unsorted-array?rq=1

if you only do high-level code and have no clue about compiler optimization and how assembly and cpu cycle with pipelines work, it makes zero difference to you

but as mentioned the code was 6 times as fast or nearly 10 more seconds with n only =100k

theres always things like that, and hence why imo cache, virtual memory and assembly has to pretty much at least be in the back of your head when coding

but yeah compiler class just gave me a lot of insight on things where it wasn't obvious how compiler does translation/optimizations. plus writing your own compiler was fun lol

 

[Type Username Here]

theres always stuff that if you just do high-level you miss on, because it makes visibly no difference on high level yet it does on low level and you get drastically different results. shyt like that is really obvious when you start going in depth on compilers

for example, http://stackoverflow.com/questions/...rted-array-faster-than-an-unsorted-array?rq=1

if you only do high-level code and have no clue about compiler optimization and how assembly and cpu cycle with pipelines work, it makes zero difference to you

but as mentioned the code was 6 times as fast or nearly 10 more seconds with n only =100k

theres always things like that, and hence why imo cache, virtual memory and assembly has to pretty much at least be in the back of your head when coding

but yeah compiler class just gave me a lot of insight on things where it wasn't obvious how compiler does translation/optimizations. plus writing your own compiler was fun lol

Great post and link.

I wish I could read what happened at Nintendo with the WiiU operating system. When it first came out, there was huge waiting times between menu screens, loading issues, latency and other problems. They spent a few months cleaning it up. Loading times dropped nearly 20 seconds in some cases. It was then optimized again and there was more improvement.

Just goes to show how important efficiency in coding and understanding the hardware and kernel really is.

 

[OCCAMS_RAZOR]

theres always stuff that if you just do high-level you miss on, because it makes visibly no difference on high level yet it does on low level and you get drastically different results. shyt like that is really obvious when you start going in depth on compilers

for example, http://stackoverflow.com/questions/...rted-array-faster-than-an-unsorted-array?rq=1

if you only do high-level code and have no clue about compiler optimization and how assembly and cpu cycle with pipelines work, it makes zero difference to you

but as mentioned the code was 6 times as fast or nearly 10 more seconds with n only =100k

theres always things like that, and hence why imo cache, virtual memory and assembly has to pretty much at least be in the back of your head when coding

but yeah compiler class just gave me a lot of insight on things where it wasn't obvious how compiler does translation/optimizations. plus writing your own compiler was fun lol

damn breh, that's insane

do you have any good resources for someone who wants to self-learn the basics (and other low-level minutiae)? i'm almost out of the school system and can't benefit from a formal education anymore. i'm definitely going to have to read up on compilers. i'm a performance nut, and hate how i have no idea what's going on bit by bit most times.

Great post and link.

I wish I could read what happened at Nintendo with the WiiU operating system. When it first came out, there was huge waiting times between menu screens, loading issues, latency and other problems. They spent a few months cleaning it up. Loading times dropped nearly 20 seconds in some cases. It was then optimized again and there was more improvement.

Just goes to show how important efficiency in coding and understanding the hardware and kernel really is.

hey i tried searching up the story of PONG but was unable to find resources that really went deep into the entire thing. do you have any good websites / books you can recommend?

 

[yseJ]

damn breh, that's insane

do you have any good resources for someone who wants to self-learn the basics (and other low-level minutiae)? i'm almost out of the school system and can't benefit from a formal education anymore. i'm definitely going to have to read up on compilers. i'm a performance nut, and hate how i have no idea what's going on bit by bit most times.

nah I dont have anything concrete right now, its been a while. I cant even name the few compiler books Ive used...lol

dont want to get too philosophical here, but experience and drive to learn is basically your best friend. especially in CS where you learn something new every single day. books and online guides and stuff like stackoverflow are great as a supplement, but experience and just writing and exploring stuff is always how you feel you really know stuff.

for devs, I also cannot stress the importance of testing your code. it will make you a better coder and you get into habit of fully thinking out scenarios, and not just bsing on design docs and think inside the box only about the positive scenarios

testing code isnt quite for qa dolts, a good tester who can do both whitebox and blackbox is hard to find, so you might as well whitebox yourself- it will make you a better coder, 100% guarantee

 

[kevm3]

Glad to see the thread still going strong and all kinds of discussions going on. This is the kind of stuff programmers need to hear to improve.

This weekend I've been playing around with angular.js. It's a strange framework, but I'll have it down within a few weeks.

 

[OCCAMS_RAZOR]

dont want to get too philosophical here, but experience and drive to learn is basically your best friend. especially in CS where you learn something new every single day. books and online guides and stuff like stackoverflow are great as a supplement, but experience and just writing and exploring stuff is always how you feel you really know stuff.

you're basically right though. now that you and @Type Username Here have got me hip to this, i have a burning desire to really know what's going on at the assembly level. i absolutely will not stop until i find out.

anyways, great to be talking to experts here, lol. usually i log into the coli to fukk around but i'm actually learning stuff here. it would be great if you could share any more solid insights you've collected over your time working as an engineer.

what do you think about analyzing algorithms, and big-oh. i feel like there's a schism. there's the folks who say that you don't really need to worry about that stuff, if youu're just doing minor things. however, for the ppl working at amazon, facebook and google where you are dealing with large data, having an algorithm with a good worst-case running time could be the difference between meeting that deadline and getting fired.

 

[OCCAMS_RAZOR]

also what's everyone's opinions on recursion? generally it's an expensive procedure, and i've even heard some developers say that it should not be taught in schools. of course some problems can't be adapted very well to a looping algorithm so recursion is your only option, but generally speaking, when you've got a choice between doing something in a loop and doing something with recursion, recursion is going to be the more efficient alternative.

 

[yseJ]

you're basically right though. now that you and @Type Username Here have got me hip to this, i have a burning desire to really know what's going on at the assembly level. i absolutely will not stop until i find out.

anyways, great to be talking to experts here, lol. usually i log into the coli to fukk around but i'm actually learning stuff here. it would be great if you could share any more solid insights you've collected over your time working as an engineer.

what do you think about analyzing algorithms, and big-oh. i feel like there's a schism. there's the folks who say that you don't really need to worry about that stuff, if youu're just doing minor things. however, for the ppl working at amazon, facebook and google where you are dealing with large data, having an algorithm with a good worst-case running time could be the difference between meeting that deadline and getting fired.

algorithms and big oh is a staple of things. if you cant analyze algorithms, you cant really program lol. its quite easy too, nothing complicated as long as you can do medium-level math.
I wouldnt put it as a way of meeting deadline, its just one of those things you use all the time to make design decisions. its really a building block of things that you just kinda have to know. I dont think theres a way around it once you write code that resembles real-world projects

 

[kevm3]

also what's everyone's opinions on recursion? generally it's an expensive procedure, and i've even heard some developers say that it should not be taught in schools. of course some problems can't be adapted very well to a looping algorithm so recursion is your only option, but generally speaking, when you've got a choice between doing something in a loop and doing something with recursion, recursion is going to be the more efficient alternative.

Recursion is something I've been trying to figure exactly what it is. I know essentially a function calls itself, creating a sort of loop, but where and why is it used?

 

[yseJ]

also what's everyone's opinions on recursion? generally it's an expensive procedure, and i've even heard some developers say that it should not be taught in schools. of course some problems can't be adapted very well to a looping algorithm so recursion is your only option, but generally speaking, when you've got a choice between doing something in a loop and doing something with recursion, recursion is going to be the more efficient alternative.

I dont get why it should not be taught, recursion is a great concept and makes for really simple, elegant solutions to some basic problems. recursion is easily explained when explaining the stack, so
pretty much any tree traversal question youre gonna be asked on a interview will involve recursion

it is expensive in general, but its only when there are a LOT of calls so stack overhead starts growing with each new frame. also lots of new compilers I believe will replace recursion with iterative version.

also pretty much any programming problem that can be solved by recursion can be solved iteratively. I think math has some problems and things that cannot be expressed without recursion but theyre very far and between.

recursion is just much more easy and elegant in certain cases which include nodes, children and nesting