|
Experience tells me building an API is often more work than building the guts. And it often involves more creativity.
Now, do I want to preclude someone being able to assert a copyright over something that is unique and imbued with creativity and a lot of work? Gotta say "no".
One good thing might come out of this: Licenses should cover implementation and API as separate items.
|
|
|
|
|
sorry if this dates me too much, but I kind of miss the pre-internet days working as a dev.
Technology didn't move that fast, a new compiler would be available every great once in awhile. You could keep most libraries in your head because they rarely ever changed. Most of the time you were only limited by imagination and memory (ram).
So you would subscribe to any tech magazine to get the latest info. there would be code samples of something clever, articles on the pitfalls of a language feature, or work progress of getting a new complier up and running.
My shelves were packed with any books I could get ahold of and every magazine that had something interesting.
The internet is the first tool I have to reach for now. there is just soo much to know and it's almost impossible to keep it all in your head. For me to remain a dev until retirement is going to be a stretch, so I'm thinking of going into education to tech software development.
I've notice that many of the younger devs out there can slap something together that works, but don't any have the fundamentals on how any of it works underneath: they can put gas in the car, but have no idea what's under the hood that makes it go, and that bothers me.
any other gray beards out there seeing the same thing?
|
|
|
|
|
I definitely see this going on, but I think a lot of new devs know they are missing out on things too.
I have here Jeff Prosise's great book, Programming Windows with MFC and it weighs in at over 1200 pages.
I also have the Petzold Programming Windows 95 and it is around that length also.
But, the Internet has ruined strong focus. Read the book, The Shallows: What the Internet is doing to our brains[^].
Petzold went into specifc details and you had to learn how things were really built up.
But a lot of people didn't like that. It is somewhat of the Engineering Mindset.
Some people just want to get a thing working and forget about it. They want the end result.
Others (with Engineering Mindset) want to know exactly how things work.
I find that when I want a PRODUCT I want to get the thing working.
But most of the time I want to know exactly how the thing works. It's two different mindsets really.
|
|
|
|
|
thanks for the book recommendation, I just put that in my cart.
raddevus wrote: But most of the time I want to know exactly how the thing works. It's two different mindsets really.
I think you summed that up perfectly.
I worked for someone once that was the quickest person I've ever seen to refactor code, 1000's of lines of code in a day. It was garbage of course, he didn't know how to debug so everything was in a try/catch/fail -> send to log file. this code went in to production without ever testing locally, and he would wait for logs to appear, then change something upload to customer and watch the logs again. and again, and again.
Another had no idea what bit wise operations were and was confused on exactly what an integer was, let alone the size of integer and how much it could hold. But he was still putting Apps together.
[head shake]
|
|
|
|
|
|
Matt McGuire wrote: Another had no idea what bit wise operations were and was confused on exactly what an integer was, let alone the size of integer and how much it could hold. But he was still putting Apps together.
Yep, I've worked with the same kind of people.
We had a guy who didn't seem to know what a function was used for.
He had a bug in a for loop that was copy pasted into his code dozens of times. It failed in production when he was out of town and unavailable so we had to fix it. Had to search thru for dozens of instances of the bug and replace them. If it were wrapped in one function call...
Oy!
|
|
|
|
|
raddevus wrote: He had a bug in a for loop that was copy pasted into his code dozens of times. It failed in production when he was out of town and unavailable
I would hope that his boss contacted him, and told him not to bother coming back...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: I would hope that his boss contacted him, and told him not to bother coming back...
Boss didn't take action because this employee represented head-count to the boss and kept his Management Kingdom larger than if he started getting rid of people. 
|
|
|
|
|
A code review should have caught the duplication.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Matt Bond wrote: A code review should have caught the duplication.
Yes, but this was a long while ago now -- around 2000 -- and this particular place allowed developers to work autonomously. Each dev managed his/her own services.
That's good and bad, I know.
That was a great thing if you were apt to do it all and "own" your stuff.
This guy was not up for that though and it became obvious in production some time after midnight.
|
|
|
|
|
I'm with you on that. One of the things that I find frustrating with some so-called devs, is not that the lack the fundamentals, but they seem not to have any idea what to do if things go wrong. If their code does not run or throws an error they are incapable of doing some basic diagnosis. There have also been three questions posted here in the last few days from people who are trying to use third-party products. They don't know the product, or some part does not do what they want, so rather than going back where they got it from and asking people who would know, they post a question here. Similarly with homework questions under "what have I done", we see things like, "nothing because I don't know how to start". I just hope that all the developers who never post a question here are of a much higher calibre.
|
|
|
|
|
Yes, a sea change from the days when I used to debug in hex, over the phone.
Eliminating possible causes of a bug until, to steal a phrase, what remains must be the truth, requires the ability to think deductively, which is rooted in logic. In an age where emotions are treated like facts, the ability to debug this way is severely compromised.
|
|
|
|
|
I got a job after debugging by phone.
I was working in Germany using software from a company in the US. There was an intermittent bug that was driving us crazy and the company could not fix it. The president of the company had me describe the bug in detail to one of his developers so they "could better fix it". I ended up describing to him the steps it must have gone through and the kind of code it must be running at the point the bug came up - he found the appropriate code and I said something like:
"...and then it will have a pointer to a block that it constructs the message string in before adding the terminating null at the end of the string";
"Yes, there is a pointer for the message";
"Has it allocated enough memory for the block? Perhaps it didn't allow for the terminator.";
"Allocated memory?";
...at which point the problem was solved! The president had been listening in on the call and immediately offered me a job.
Ah, the good old days!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
|
Richard MacCutchan wrote: what have I done", we see things like, "nothing because I don't know how to start".
You are correct about many devs not being able to debug. It is probably why the ability to debug, or just get something going again when it is stuck, is probably the number one ability to look for in a dev.
- Brian W. Kernighan "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
|
|
|
|
|
|
DerekT-P wrote: we learned how to dismantle things!
I did much the same at home. Like you I did not always understand how the things worked but I did learn how to try and find out.
|
|
|
|
|
Funny. My uncle and some of his other retired buddies took over the science department at a private school. Labs include multi week disassembly of small 4 cycle engines, using long cables like jump ropes to detect Earth's magnetic field, etc. Sounds like a similar mindset.
|
|
|
|
|
My elder brother loved to dismantle things to see how they worked. 
I had to figure out how they worked so I could out them back together again - a skill my brother never quite got the hang of.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
My elder brother was too busy chasing skirt to care about the internal workings of any machine.
|
|
|
|
|
I dismantled a lot of things before I learned how to put them back together. 
|
|
|
|
|
I certainly don't want to go back to finding the appropriate MSDN documentation CD out of the folder of 12 that will have the documentation for Substring as I don't know if it is SubString or Substring as IntelliSense hasn't been invented either.
The internet has certainly made it easier to plagiarise though and has defo made it easier to find examples of larger sections of code, as well as (obviously) places people can just post their homework expecting someone else to do it for them. I'd hate to be a lecturer these days, half the job must be trying to work out if people have got others to do their work.
|
|
|
|
|
the CDs were horrible, ended up getting a second hard drive just to load up the MSDN library, but the information did tend to be more technically accurate with actual examples (for the most part)
I can't tell you how many times working with a new API lately and I look up the docs and it only has the name and the signature like:
void ThisIsSomeSortOfAPI(int count)
param int count - count to pass to API
defination: This is Some Sort Of API
I'm like thanks that is so helpful
|
|
|
|
|
F-ES Sitecore wrote: I'd hate to be a lecturer these days, half the job must be trying to work out if people have got others to do their work.
True, but you could probably weed most of them out just by asking a specific question about "their" code. They'll end up convicting themselves.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
My daughter is a TA/grader for one of those classes. First thing each week, find answers to home work online. Then she can tell if someone just copied and pasted them for their own answer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
