Long term career advice
-
:), also true.
.net is a box of never ending treasures, every day I get find another gem.
No, I think it is simply another facet to the same argument. Unix and Java, or Solaris and Java, are the OS and language of choice for 'that type' of programmer, in the same way that Windows and C++ or Windows and C#/VB.Net are tightly linked. Anyway, I've lived in 4 decades, so I suspect your argument is null. and void. :D Long live SC/MP machine code!
-
Nathan A. wrote:
My apologies for offending you with what I intended to be an honest question.
No apologies necessary. I was being flippant because I couldn't figure out what the question even was.
Nathan A. wrote:
how about answering the question?
I'd love to. But where's the question. There's not a single sentence that ends in a questionmark. I'll look again. :)
Nathan A. wrote:
How would you evaluate that person?
The lack of windows experience wouldn't necessarily be an issue for a platform independent job. I'd interview with more general questions about the technologies that are cross-platform. There's lots of stuff to ask about db's that has nothing to do with the OS or even the specific DB product. I'd look for diversity in experience, as this indicates flexibility and experience with difference products, which all have their own quirks. Of course, that would mean that I as the interviewer would probably need some minimal understanding of the different products so I could ask more intelligent questions besides "what's the difference between Postgres and MySQL?"
Nathan A. wrote:
what sort of minimum knowledge would you want them to have in order to give them the job?
How else can the person contribute to the company? I personally hate being "niched". I think it's bad for the task and the company. So I'd look for things that person knows that rounds him/her out as an overall useful CS person. Hope that helps! Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
Hope that helps!
It does, and thank you very much for helping me out with this. Sorry for responding a little brusquely to your comment. I think I understood it to mean something other than what it was: good natured ribbing at not actually including a question mark anywhere. Your answer actually clears things up a great deal though. I remember starting out doing more serious work on linux. One of the toughest things for me was just getting up to speed on using the system (understanding "makefile" thinking, the actual syntax to invoke compilers/linkers from the command line, and things like that). I'd hate to think that my inability to do the same things on Windows could prevent me from getting to where the action is. For example, if someone posed a novice Windows question in an interview: write a simple program that calls a single function from some library and then build it, I would be totally sunk. I simply don't know how to use the Windows tools to get that done. I can only assume that being unable to compile and run a hello world application is the sort of thing that that can make you look like a fool in an interview pretty quickly. Good to know that people out there might be willing to ignore obvious superficial deficiencies and look to the more substantive stuff. Thanks.
-
Marc Clifton wrote:
Hope that helps!
It does, and thank you very much for helping me out with this. Sorry for responding a little brusquely to your comment. I think I understood it to mean something other than what it was: good natured ribbing at not actually including a question mark anywhere. Your answer actually clears things up a great deal though. I remember starting out doing more serious work on linux. One of the toughest things for me was just getting up to speed on using the system (understanding "makefile" thinking, the actual syntax to invoke compilers/linkers from the command line, and things like that). I'd hate to think that my inability to do the same things on Windows could prevent me from getting to where the action is. For example, if someone posed a novice Windows question in an interview: write a simple program that calls a single function from some library and then build it, I would be totally sunk. I simply don't know how to use the Windows tools to get that done. I can only assume that being unable to compile and run a hello world application is the sort of thing that that can make you look like a fool in an interview pretty quickly. Good to know that people out there might be willing to ignore obvious superficial deficiencies and look to the more substantive stuff. Thanks.
Nathan A. wrote:
Sorry for responding a little brusquely to your comment.
No problem. It's me--I sometimes get rather sarcastic.
Nathan A. wrote:
I'd hate to think that my inability to do the same things on Windows could prevent me from getting to where the action is.
I'm in totally the other boat. I've completely forgotten and wouldn't know where to start setting up a make file. Visual Studio sure spoils you. My dabbling in Linux has left me running away screaming, as I can't understand why there aren't simple UI's to manage all the source file builds.
Nathan A. wrote:
I can only assume that being unable to compile and run a hello world application is the sort of thing that that can make you look like a fool in an interview pretty quickly.
Sure. Grab Visual Studio Express and give it a try. It's amazing how easy it is actually. The point is, learning the tool is actually easy in comparison. But frankly, what really galls me is watching people use the mouse to cut and paste code up or down a couple lines. And these are experienced programmers. Sigh. I do expect, actually demand, that people I work with know how to use their tools efficiently. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Nathan A. wrote:
Sorry for responding a little brusquely to your comment.
No problem. It's me--I sometimes get rather sarcastic.
Nathan A. wrote:
I'd hate to think that my inability to do the same things on Windows could prevent me from getting to where the action is.
I'm in totally the other boat. I've completely forgotten and wouldn't know where to start setting up a make file. Visual Studio sure spoils you. My dabbling in Linux has left me running away screaming, as I can't understand why there aren't simple UI's to manage all the source file builds.
Nathan A. wrote:
I can only assume that being unable to compile and run a hello world application is the sort of thing that that can make you look like a fool in an interview pretty quickly.
Sure. Grab Visual Studio Express and give it a try. It's amazing how easy it is actually. The point is, learning the tool is actually easy in comparison. But frankly, what really galls me is watching people use the mouse to cut and paste code up or down a couple lines. And these are experienced programmers. Sigh. I do expect, actually demand, that people I work with know how to use their tools efficiently. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh SmithMarc Clifton wrote:
I can't understand why there aren't simple UI's to manage all the source file builds
That is an excellent point. I'm sure something like that exists on Sourceforge, but I've never encountered such a thing. It does seem like it would be really useful. My guess is that the big OSS IDEs all have their own project management, and their users probably just use that (I'll bet they output makefiles, but only automatically). I suspect that the people who handwrite makefiles are the same group of people who are doing development on the command line + emacs/vi/another super text editor. Within that culture, for whatever reason, GUI tools usually tend to be avoided. I suspect the big reason for that is that when the solution for all your problems is to write a script, a GUI application can isolate a bunch of your workflow from the rest of your tools. 100% Gui good, 100% command line good, but combinations have never really worked out for me. Mixing and matching the different types of tools always seems to lead to permanent cognitive dissonance. Makefiles are powerful, but are rarely worth the trouble. Basically they let you define arbitrary rules for building things, given the existence of the objects the about-to-be-built object depends upon. This can let you do very powerful things (the first big makefile system I saw was built on the concept of the makefile rules generating other rules, based on results gained by iterating through the directory structure). The problem is that 99% of building software all goes in the same way: where there are two object types (include a third -- object files -- if you want), binaries and libraries. Each of those is basically built in the same way, by compiling code and linking it with libraries. The problem is that I can't think of an easy way to implement this. About the best system I can think of would somehow define some build primitives(object file, binary, static library, dynamic library and so forth), and would require a single file that indicates what the product of each directory is, and what objects that product depends on (ie, Rule 1: the main binary is built from the files in directory main/, and depends on the dynamic library foo. Rule 2: foo is a dynamic library built out of the contents of the directory lib/foo.). The problem then is that this system is basically exact same system as the one I just said I hated so much! The other option would be to just write explic
-
It's true, you're either Windows or Unix there's no in between. I choose Windows in '90 after toiling with Pick and Pick/Unix.
.net is a box of never ending treasures, every day I get find another gem.
Yeah, I agree! I do not see any sense in hiring a developer on a Unix based box to do Window's development since they are really two different worlds. Yes, a person may have an understanding of a specific programming langauge, but I think that is the small part, the large part is the OS API/Frameworks. Much like .NET, learning C# is trivial for a C++ developer, but learning the massive .NET framework, that this the real skill.
Rocky <>< Latest Code Blog Post: OpenID - More thought - Great system if.. Latest Tech Blog Post: Corel Lightning - what is the plan?
-
Marc Clifton wrote:
Hope that helps!
It does, and thank you very much for helping me out with this. Sorry for responding a little brusquely to your comment. I think I understood it to mean something other than what it was: good natured ribbing at not actually including a question mark anywhere. Your answer actually clears things up a great deal though. I remember starting out doing more serious work on linux. One of the toughest things for me was just getting up to speed on using the system (understanding "makefile" thinking, the actual syntax to invoke compilers/linkers from the command line, and things like that). I'd hate to think that my inability to do the same things on Windows could prevent me from getting to where the action is. For example, if someone posed a novice Windows question in an interview: write a simple program that calls a single function from some library and then build it, I would be totally sunk. I simply don't know how to use the Windows tools to get that done. I can only assume that being unable to compile and run a hello world application is the sort of thing that that can make you look like a fool in an interview pretty quickly. Good to know that people out there might be willing to ignore obvious superficial deficiencies and look to the more substantive stuff. Thanks.
Hi Nathan, I was wondering why knowing anything about Windows would be of any interest to a future employer if the job/technology you target is not platform dependant? That is, why would you expect issues about the lack of knowledge of Windows, if this is not part of the job description? Little confused here :confused:
Rocky <>< Latest Code Blog Post: OpenID - More thought - Great system if.. Latest Tech Blog Post: Corel Lightning - what is the plan?
-
No, I think it is simply another facet to the same argument. Unix and Java, or Solaris and Java, are the OS and language of choice for 'that type' of programmer, in the same way that Windows and C++ or Windows and C#/VB.Net are tightly linked. Anyway, I've lived in 4 decades, so I suspect your argument is null. and void. :D Long live SC/MP machine code!
-
Hi Nathan, I was wondering why knowing anything about Windows would be of any interest to a future employer if the job/technology you target is not platform dependant? That is, why would you expect issues about the lack of knowledge of Windows, if this is not part of the job description? Little confused here :confused:
Rocky <>< Latest Code Blog Post: OpenID - More thought - Great system if.. Latest Tech Blog Post: Corel Lightning - what is the plan?
It seems to me that running code on one platform versus another will have two big differences. The first is that actual system calls will be different. (On linux, to get the current time in ticks (or whatever they are caled), you include the file time.h and then use the function time(NULL) to get the current time). When I mean platform independent code, I mean code that doesn't use any of these specific plaform functions, or at least code that wraps any platform dependent functions so that within application code the function calls are all unified under one internal API (this would be like having some conditional compilation that says something like #ifdef WIN int myTime() = { return WinTime();} #ifdef LINUX int myTime() = {return Time(NULL);}. The second way it's different will be that you just need to use a different set of tools in order to work on that platform. While a hello world program will compile and run on windows in exactly the same way as linux, that actual compiling process is different. My worry is that even though I'd be looking at projects that don't have much to do with the first type of difficulties, I expect the second kind will be very important, and that's what I'm concerned with not knowing. Even the most platform-independent project is going to want people to be able to build the software, which necessarily means you'll have to know a little something about the system you're trying to build on. For example, the work I do currently is on C++ projects with platform independent code based on linux systems. Nevertheless, I expect that someone who was totally used to windows would have some real adjustment time coming to work on our project, just because they would have to relearn some of their basic tools. If they want to do a search of the code, they'll probably be using grep; to compile they'll probably use g++, and so on. The barriers involved in changing platforms that are caused simply by working on that system itself are what I'm concerned about. It's funny, because in the end, it's the exact same set of factors that gets my grandma to stick to a particular OSes: not because it's particularly suited to what she does, let alone the only system that can do those things (email and internet), but just because she knows where the email button is and simply doesn't want to have to relearn that. It's a perfectly legitimate reason, I just feel I have a stake in keeping myself a little more flexible in where I can work than good ole' grandma.
-
Gizz wrote:
I've lived in 4 decades
And you're saying I haven't? ;)
.net is a box of never ending treasures, every day I get find another gem.
-
It seems to me that running code on one platform versus another will have two big differences. The first is that actual system calls will be different. (On linux, to get the current time in ticks (or whatever they are caled), you include the file time.h and then use the function time(NULL) to get the current time). When I mean platform independent code, I mean code that doesn't use any of these specific plaform functions, or at least code that wraps any platform dependent functions so that within application code the function calls are all unified under one internal API (this would be like having some conditional compilation that says something like #ifdef WIN int myTime() = { return WinTime();} #ifdef LINUX int myTime() = {return Time(NULL);}. The second way it's different will be that you just need to use a different set of tools in order to work on that platform. While a hello world program will compile and run on windows in exactly the same way as linux, that actual compiling process is different. My worry is that even though I'd be looking at projects that don't have much to do with the first type of difficulties, I expect the second kind will be very important, and that's what I'm concerned with not knowing. Even the most platform-independent project is going to want people to be able to build the software, which necessarily means you'll have to know a little something about the system you're trying to build on. For example, the work I do currently is on C++ projects with platform independent code based on linux systems. Nevertheless, I expect that someone who was totally used to windows would have some real adjustment time coming to work on our project, just because they would have to relearn some of their basic tools. If they want to do a search of the code, they'll probably be using grep; to compile they'll probably use g++, and so on. The barriers involved in changing platforms that are caused simply by working on that system itself are what I'm concerned about. It's funny, because in the end, it's the exact same set of factors that gets my grandma to stick to a particular OSes: not because it's particularly suited to what she does, let alone the only system that can do those things (email and internet), but just because she knows where the email button is and simply doesn't want to have to relearn that. It's a perfectly legitimate reason, I just feel I have a stake in keeping myself a little more flexible in where I can work than good ole' grandma.
In today's world I think there is a greater divide on the platforms for "application" programming as Windows is moving more to .NET WPF, WCF type systems, which is a vast change from old Windows API type development where even C++ looks alien. Developing platform independent code will grow harder in the near future. So, I probably would not worry about if compiling a program with tools on Windows will be a barrier their are much bigger fish to fry. That said though, the newer technologies available under .NET are really making it much easer to write software, although for most that means in another language (such as C# or VB.NET, C++ for most people - hey Nish, I said most people :) - does not cut it in .NET). C# for example keeps evolving and has become (3.0) quite a nice development lanaguage. I agree that you could pick up one of the free versions (Express editions) of Visual Studio and play around. For those that like the command line life, there are still command line tools on Windows, but many developers like myself, have became lazy and just use the GUI ;)
Rocky <>< Latest Code Blog Post: OpenID - More thought - Great system if.. Latest Tech Blog Post: Corel Lightning - what is the plan?