Wow, not only are you a poor software engineer (if even that) - you're a liar as well.
"You honestly believe that the only documentation for code is commenting" - Really? Despite my posting the following?
(3)Design writing - Part of documenting code (4)Implementation comments - Part of documenting code (5)Updating design - Part of documenting code
Followed by dishonesty about what you yourself posted:
I did not anywhere say I didn't have time for it...
Funny, if your first post you state, clearly (perhaps not clearly enough for yourself):
I've never had a problem of incentive or motivation to document my code; my problem is and always has been time
Never worked anywhere? LOL.
I've been directly involved in the leadership of architecture and development for more than 5 companies - 3 of which were sold to for more than 60 *million* dollars (aggregated startup costs of less than 10 million dollars.)
I own my own ISV startup currently, and I am also simultaneously the CTO of another successful ISV. I'm also on the advisory board to a large private equity firm as their technical resource and I perform all of their technical due diligences.
Needless to say, statistically speaking I am *likely* to be much more experienced and battle tested software engineer than yourself, kid...
Your third point is in complete contrast to your first two and just cements your status as the village idiot.
Funny, perhaps you should provide quotes so people have some idea what you're referring to here - I don't want to spend anymore time than necessary pointing out you flailing inadequecies as an "engineer."
I'm happy to hear that you've performed an "anecdotal survey" of everyone you've ever worked with at the "Code Academy."
Documenting your code is a multi-part process, including comments in your code; unless, of course, you'd like to argue that putting proper comments in your code is not part of documenting your code at all...
Let's break this process down for you since you seem to think it is a one aspect problem.
This process works in smaller iterative cycles for some teams, in larger iterative cycles for some teams, and in a monolithic cycle for some teams. Some teams aggregate Requirements Gathering and Specification writing.
(1)Requirements gathering - Nothing to do with documenting code (2)Specification writing - Nothing to do with documenting code (3)Design writing - Part of documenting code (4)Implementation comments - Part of documenting code (5)Updating design - Part of documenting code
You claim that you don't have time to do #3 or #5.
That's because you're acting like a programmer, not a software engineer.
If your pre-implementation designs are so different from your end results, the problem isn't that you don't have time to document properly, the problem is that you design poorly. If those designs change due to external influences (such as changing specifications/requirements) then the problem isn't that you don't have time to document properly, the problem is that you handle your customers poorly.
You want to argue that proper documentation doesn't have anything to do with code commenting? Well, let's just hope you stay a programmer then because code documentation's purpose is to, bluntly, give your company/employer/client a way to continue when you stupidly walk in front of a bus.
The majority of the benefit is in well commented (to differentiate for you since you would interpret documented to be external documents) code. Architectural overviews are valuable, but trivial to write and maintain. High level feature documentation should happen in both external documentation and in the code base. Low level feature documentation of code should not be in an external document, but primarily just in the code unless it is something extraoridinary (such as an obscure 3D rasterization optimization technique from the early 90's that you had to use for some reason.)
Please learn to be a software engineer "before writing another line."
This is why you "document your code" as you write it.
There's no reason you can't document your code as it is being written, in fact, it's the best time to do it because the documenting the *reason* you choose to do something a particular way can actually be more important than ensuring that the following code is easy to follow.
There are, of course, limits to what you should document in code. For example, I wrote a software renderer in Java two years ago and there is a section that relies on some hidden surface removal techniques covered well in Abrash's book(s) but very complicated to explain in the level of detail that any software engineer would understand because explaining it relied on a corpus of knowledge not common to software engineers. My documentation in the code explained it rudimentarily and then pointed anyone else reading it to some references for greater understanding. That was the one place in the code I did that, and it was the first time I've done that in code comments before.
BTW, it is quite often more valuable to give your variables and arguments clear names that intimate their usage and intent than over the top code commenting - but it all helps.
Most managers don't understand that they need proper code documentation (much less what "proper documentation" actually is), architectural documents, design documents, et cetera. They only realize it when it is too late and they need it. Then they blame the programmers.
Now, I don't expect much out of a "programmer" personally. A "software engineer", however, I DO expect better from.
A software engineer shouldn't have to be told how to do their job properly.
It's easier to develop for in one sense, and more difficult in another.
The majority of application development is simpler than iOS, but the deployment testing (as this article attests) can be problematic. It really depends upon what you, as a developer, want to do with your app and your willingness to engineer that app properly.
I develop for both platforms, and think they're both great (although I think someone should urinate on Jobs' grave for making you buy a Crapintosh just to build iPhone/iPad applications. BTW, I'm only averse to Macs because they're HYSTERICALLY overpriced for what you get, I think OSX is excellent.)
I'm interested in trying out Windows Phone development too (I know, it's been out for a while.) Microsoft has almost always been a very good development environment irrespective of platform.
That being said, there's still value in these types of books for some.
I first started taking software seriously (having dabbled throughout childhood) when I bought a copy of http://www.amazon.com/Learn-Three-Days-Popular-Applications/dp/155622298X and Turbo C++ (in 1991?) before a really long deployment to the Pacific. Now, it took me more than three days to really *get* pointers, LOL, but that little digest of a book was a wonderful start for me. 20 years later, I am a very senior software engineer and a CTO.
Anything 'might' be innovation, the likelyhood is that there is none, especially given the patents I've reviewed. Hell, my company owns a patent that is reasonably innovating in the field of Natural Language Processing, and it is RIDICULOUSLY broad. Basically, if you perform a statistical analysis of textual input (including input from a voice recognition system) in order to discern a goal or request of the initiator you're bordering on a patent violation - how crazy is that? The patent office should never have approved it without greater specificity.
The good news is that we filed it for self-protection purposes, the bad news is that I may not always be making the tech decisions for this company, we may be purchased in the near future - who knows what that means for the patent. Technically a whole slew of IVR systems are in violation of it.
Software Patents need to go away. The harm far outweighs the good.
FFS, 90% of the patents you hear about are things that simply come from a software engineer implementing a feature the way just about any other software engineer would do it. It's "obvious" that this is a potential solution.
I can understand patenting things that seem to be game changers, real breakthroughs (some algorithmic work for example), but methods of previewing images? The Amazon 'one-click' patent? FFS, how that hasn't been "obvious"ed to death, I'll never know. Hmmm, do you think people like to do things easier or faster. What? Remember their default choices and offer them a "do the same sh** you did the last time I bought something" button? HOLY CRAP THAT IS GENIUS! Lol...
...a software company. They went to a bunch of government hack jobs like Lockheed Martin.
They can build an airplane, but I can tell you from personnel experience with 3 different divisions of theirs (ones doing military simulation, ones doing wide area security, and ones doing AI driven content management) they staff their people with plodders.
I don't mean the people aren't capable of writing some software, but it is TOTALLY beyond them to write a complicated system. I would never hire any of the people I interacted with over there. I'm not some friggin' elitist either, I'm good, I'm not great. These guys don't even approach good in a general sense.
I'm sure there are some good software engineers there, you just never meet any of them.
305 million dollars? FFS, There's no software project on earth that should cost HALF of that. Hardware, data entry, support, upgrades, everything included. It's ridiculous.
Seriously. Work for an ISV (Independent Software Vendor) this summer.
Better yet, if you're really adventurous (since you're going to be 15), get an internship at CRS4 - a really neat place in Sardinia (Sardegna) about 25 miles from Cagliari. Sardegna is an incredibly beautiful place (I lived there for a few years, but up north in Sassari.)
It turns out that they stopped hijacking your URLs in the browser, you can look at things in the market, you can't actually buy/download/install anything from it.
Presumably you're being put in this position because you have at least some development experience that your compatriots in tech do not and the company thinks you also have leadership potential. Stop telling yourself you're an executive for one thing, you're a manager. In a few years, with a lot of luck and hard work (which includes stepping on the defenseless, the helpless, and the needy - usually) you may get to an executive position, but I doubt it.
You're probably going to absolutely detest management (unless you were a crap developer) because you lose the ability to feel like you actually did something constructive every day; so, my advice to you - don't divorce yourself from the tech entirely. Take the management position, stay a part of the architectural discussions (presuming you have the expertise, if you don't take part in the discussion with your mouth closed), give yourself a development task - usually the best thing you can do for your team is whichever aspect of the system is the most boring or intimidating (again presuming you have the skills to do this), basically whichever aspect they want to do the least...
90% of managers are crap because they don't treat the 'management' part of it like a job, they focus entirely on the reporting aspect of it (always looking upwards syndrome) where they are only worried about what their boss thinks of them as a manager - not their people. 5% of the remaining managers are crap because they develop an 'us versus them' philosophy where they cultivate a positive (at first) team spirit by making everyone else in the company the enemy and having the development team look out for each other. A great idea for about 2 months. The last 5% of managers are those who get the balance right, those who understand that companies have needs that sometimes outweigh the immediate happiness of its employees, and that employees have needs that sometimes outweigh the immediate happiness of companies.
Being that last 5% of managers is hard, because the effort you make for those below you rarely translates into reward with those above you and the efforts you make for those above you carry no value with those below you. You simply need to accept this and do the work (which is a lot) necessary to be a good manager. It's a lot like software engineering - you either have a predilection for it or you do not. If you don't, you're going to be miserable and likely do a bad job of it.
Oh, and there's not much you can do to prepare for it except try to be yourself (otherwise embrace misery.)
Yes, everyone seems to be missing the point that it was a joke.
You can generate some good quality heat to the briefcase, but you'd need to use something like the starter (as you alluded) to convert current into voltage.
I think the actual "don't steal my hood ornament" car battery trick involves routing power through a/the starter and then when the person touches the hood ornament the connection to the battery is dropped and the starter ends up generating a lot o' volts through the ornament and ***ouch***. Just my recollection though.
Doubtful. Thieves are interested in obtaining things, not hanging around to damage your car. They would likely be more interested in looking for a different laptop to steal.
...holding laptop, make sure to solder an unobtrusive on/off switch someplace you can reach but non-obvious on the briefcase (or connected to the briefcase by wire.
Fun!:)
(I had a friend who did something similar to the hood ornament of his Dad's Mercedes during the 80's when everyone was stealing them.)
You're missing my point. Why would Apple need a 3rd party software maker to create controls/logging/diagnostic software for an operating system that it writes?
Slashdot Mirror
I'm sure that's why - lol...
Wow, not only are you a poor software engineer (if even that) - you're a liar as well.
"You honestly believe that the only documentation for code is commenting" - Really? Despite my posting the following?
(3)Design writing - Part of documenting code
(4)Implementation comments - Part of documenting code
(5)Updating design - Part of documenting code
Followed by dishonesty about what you yourself posted:
I did not anywhere say I didn't have time for it...
Funny, if your first post you state, clearly (perhaps not clearly enough for yourself):
I've never had a problem of incentive or motivation to document my code; my problem is and always has been time
Never worked anywhere? LOL.
I've been directly involved in the leadership of architecture and development for more than 5 companies - 3 of which were sold to for more than 60 *million* dollars (aggregated startup costs of less than 10 million dollars.)
I own my own ISV startup currently, and I am also simultaneously the CTO of another successful ISV. I'm also on the advisory board to a large private equity firm as their technical resource and I perform all of their technical due diligences.
Needless to say, statistically speaking I am *likely* to be much more experienced and battle tested software engineer than yourself, kid...
Your third point is in complete contrast to your first two and just cements your status as the village idiot.
Funny, perhaps you should provide quotes so people have some idea what you're referring to here - I don't want to spend anymore time than necessary pointing out you flailing inadequecies as an "engineer."
I'm happy to hear that you've performed an "anecdotal survey" of everyone you've ever worked with at the "Code Academy."
Try not being a sanctimonius ass.
Documenting your code is a multi-part process, including comments in your code; unless, of course, you'd like to argue that putting proper comments in your code is not part of documenting your code at all...
Let's break this process down for you since you seem to think it is a one aspect problem.
This process works in smaller iterative cycles for some teams, in larger iterative cycles for some teams, and in a monolithic cycle for some teams. Some teams aggregate Requirements Gathering and Specification writing.
(1)Requirements gathering - Nothing to do with documenting code
(2)Specification writing - Nothing to do with documenting code
(3)Design writing - Part of documenting code
(4)Implementation comments - Part of documenting code
(5)Updating design - Part of documenting code
You claim that you don't have time to do #3 or #5.
That's because you're acting like a programmer, not a software engineer.
If your pre-implementation designs are so different from your end results, the problem isn't that you don't have time to document properly, the problem is that you design poorly. If those designs change due to external influences (such as changing specifications/requirements) then the problem isn't that you don't have time to document properly, the problem is that you handle your customers poorly.
You want to argue that proper documentation doesn't have anything to do with code commenting? Well, let's just hope you stay a programmer then because code documentation's purpose is to, bluntly, give your company/employer/client a way to continue when you stupidly walk in front of a bus.
The majority of the benefit is in well commented (to differentiate for you since you would interpret documented to be external documents) code. Architectural overviews are valuable, but trivial to write and maintain. High level feature documentation should happen in both external documentation and in the code base. Low level feature documentation of code should not be in an external document, but primarily just in the code unless it is something extraoridinary (such as an obscure 3D rasterization optimization technique from the early 90's that you had to use for some reason.)
Please learn to be a software engineer "before writing another line."
This is why you "document your code" as you write it.
There's no reason you can't document your code as it is being written, in fact, it's the best time to do it because the documenting the *reason* you choose to do something a particular way can actually be more important than ensuring that the following code is easy to follow.
There are, of course, limits to what you should document in code. For example, I wrote a software renderer in Java two years ago and there is a section that relies on some hidden surface removal techniques covered well in Abrash's book(s) but very complicated to explain in the level of detail that any software engineer would understand because explaining it relied on a corpus of knowledge not common to software engineers. My documentation in the code explained it rudimentarily and then pointed anyone else reading it to some references for greater understanding. That was the one place in the code I did that, and it was the first time I've done that in code comments before.
BTW, it is quite often more valuable to give your variables and arguments clear names that intimate their usage and intent than over the top code commenting - but it all helps.
float[][] m_aHiddenSurfaceRemovalScanlineFragments_Z;
is much more clear than
float[][] m_aHSRFragsZ;
(Ignoring our Hungarian notation approach of course)
BTW, names like that can be a lot of typing, so we usually write, build, test, validate, refactor for clarity, then check-in.
Most managers don't understand that they need proper code documentation (much less what "proper documentation" actually is), architectural documents, design documents, et cetera. They only realize it when it is too late and they need it. Then they blame the programmers.
Now, I don't expect much out of a "programmer" personally. A "software engineer", however, I DO expect better from.
A software engineer shouldn't have to be told how to do their job properly.
It's easier to develop for in one sense, and more difficult in another.
The majority of application development is simpler than iOS, but the deployment testing (as this article attests) can be problematic. It really depends upon what you, as a developer, want to do with your app and your willingness to engineer that app properly.
I develop for both platforms, and think they're both great (although I think someone should urinate on Jobs' grave for making you buy a Crapintosh just to build iPhone/iPad applications. BTW, I'm only averse to Macs because they're HYSTERICALLY overpriced for what you get, I think OSX is excellent.)
I'm interested in trying out Windows Phone development too (I know, it's been out for a while.) Microsoft has almost always been a very good development environment irrespective of platform.
That being said, there's still value in these types of books for some.
I first started taking software seriously (having dabbled throughout childhood) when I bought a copy of http://www.amazon.com/Learn-Three-Days-Popular-Applications/dp/155622298X and Turbo C++ (in 1991?) before a really long deployment to the Pacific. Now, it took me more than three days to really *get* pointers, LOL, but that little digest of a book was a wonderful start for me. 20 years later, I am a very senior software engineer and a CTO.
Love that book! Still have it in my dev library.
Anything 'might' be innovation, the likelyhood is that there is none, especially given the patents I've reviewed. Hell, my company owns a patent that is reasonably innovating in the field of Natural Language Processing, and it is RIDICULOUSLY broad. Basically, if you perform a statistical analysis of textual input (including input from a voice recognition system) in order to discern a goal or request of the initiator you're bordering on a patent violation - how crazy is that? The patent office should never have approved it without greater specificity.
The good news is that we filed it for self-protection purposes, the bad news is that I may not always be making the tech decisions for this company, we may be purchased in the near future - who knows what that means for the patent. Technically a whole slew of IVR systems are in violation of it.
Software Patents need to go away. The harm far outweighs the good.
How obvious do things have to be?
FFS, 90% of the patents you hear about are things that simply come from a software engineer implementing a feature the way just about any other software engineer would do it. It's "obvious" that this is a potential solution.
I can understand patenting things that seem to be game changers, real breakthroughs (some algorithmic work for example), but methods of previewing images? The Amazon 'one-click' patent? FFS, how that hasn't been "obvious"ed to death, I'll never know. Hmmm, do you think people like to do things easier or faster. What? Remember their default choices and offer them a "do the same sh** you did the last time I bought something" button? HOLY CRAP THAT IS GENIUS! Lol...
...a software company. They went to a bunch of government hack jobs like Lockheed Martin.
They can build an airplane, but I can tell you from personnel experience with 3 different divisions of theirs (ones doing military simulation, ones doing wide area security, and ones doing AI driven content management) they staff their people with plodders.
I don't mean the people aren't capable of writing some software, but it is TOTALLY beyond them to write a complicated system. I would never hire any of the people I interacted with over there. I'm not some friggin' elitist either, I'm good, I'm not great. These guys don't even approach good in a general sense.
I'm sure there are some good software engineers there, you just never meet any of them.
305 million dollars? FFS, There's no software project on earth that should cost HALF of that. Hardware, data entry, support, upgrades, everything included. It's ridiculous.
Seriously. Work for an ISV (Independent Software Vendor) this summer.
Better yet, if you're really adventurous (since you're going to be 15), get an internship at CRS4 - a really neat place in Sardinia (Sardegna) about 25 miles from Cagliari. Sardegna is an incredibly beautiful place (I lived there for a few years, but up north in Sassari.)
http://www.crs4.it/
There are probably exchange parents in the area you could stay with.
Be my guest...
Thanks man, I needed a good chortle today - LOL... "may I?" LOL...
It turns out that they stopped hijacking your URLs in the browser, you can look at things in the market, you can't actually buy/download/install anything from it.
I develop for both iOS and Android right now and I'm telling you, once you read the Amazon App Store terms you're going to say "f*** that..."
...spoken to about the device say "Sorry, I won't publish through Amazon's App Store because it is sh**."
The same reason I hope the Fire fails absolutely miserably; whereas, if you could use Google Market with it I would buy one immediately.
Amazon are climbing on Google's back to create another closed system.
...an executive.
Presumably you're being put in this position because you have at least some development experience that your compatriots in tech do not and the company thinks you also have leadership potential. Stop telling yourself you're an executive for one thing, you're a manager. In a few years, with a lot of luck and hard work (which includes stepping on the defenseless, the helpless, and the needy - usually) you may get to an executive position, but I doubt it.
You're probably going to absolutely detest management (unless you were a crap developer) because you lose the ability to feel like you actually did something constructive every day; so, my advice to you - don't divorce yourself from the tech entirely. Take the management position, stay a part of the architectural discussions (presuming you have the expertise, if you don't take part in the discussion with your mouth closed), give yourself a development task - usually the best thing you can do for your team is whichever aspect of the system is the most boring or intimidating (again presuming you have the skills to do this), basically whichever aspect they want to do the least...
90% of managers are crap because they don't treat the 'management' part of it like a job, they focus entirely on the reporting aspect of it (always looking upwards syndrome) where they are only worried about what their boss thinks of them as a manager - not their people. 5% of the remaining managers are crap because they develop an 'us versus them' philosophy where they cultivate a positive (at first) team spirit by making everyone else in the company the enemy and having the development team look out for each other. A great idea for about 2 months. The last 5% of managers are those who get the balance right, those who understand that companies have needs that sometimes outweigh the immediate happiness of its employees, and that employees have needs that sometimes outweigh the immediate happiness of companies.
Being that last 5% of managers is hard, because the effort you make for those below you rarely translates into reward with those above you and the efforts you make for those above you carry no value with those below you. You simply need to accept this and do the work (which is a lot) necessary to be a good manager. It's a lot like software engineering - you either have a predilection for it or you do not. If you don't, you're going to be miserable and likely do a bad job of it.
Oh, and there's not much you can do to prepare for it except try to be yourself (otherwise embrace misery.)
Good luck.
An angry anybody will damage your car. People doing smash & grabs are interested in spending as little itme as possible at the scene.
Yes, everyone seems to be missing the point that it was a joke.
You can generate some good quality heat to the briefcase, but you'd need to use something like the starter (as you alluded) to convert current into voltage.
I think the actual "don't steal my hood ornament" car battery trick involves routing power through a/the starter and then when the person touches the hood ornament the connection to the battery is dropped and the starter ends up generating a lot o' volts through the ornament and ***ouch***. Just my recollection though.
BTW, it's a joke - *** whoosh ***
Doubtful. Thieves are interested in obtaining things, not hanging around to damage your car. They would likely be more interested in looking for a different laptop to steal.
...holding laptop, make sure to solder an unobtrusive on/off switch someplace you can reach but non-obvious on the briefcase (or connected to the briefcase by wire.
Fun! :)
(I had a friend who did something similar to the hood ornament of his Dad's Mercedes during the 80's when everyone was stealing them.)
What do I need to run the simulator too? Lol... DARPA, they rock because they do crazy sh** all the time and sometimes it works out great.
You're missing my point. Why would Apple need a 3rd party software maker to create controls/logging/diagnostic software for an operating system that it writes?