1. Prefer non-mutable data. No more action at a distance bugs. Hand off a reference to your data structure and don't have to care. Replay any data transform at any point as a unique structure. 2. Prefer a defined and well known API often involving transforms that take a function as an argument to provide the predicate (e.g., filter), transform (e.g., map), aggregation (e.g., foldLeft/Right), or whatever building block. 3. Prefer data structures that you can reason about based on a well-known set of patterns. (Best quote ever: "You say `patterns' and everyone is warm and fuzzy. You say `monad' and every loses their f-ing minds.)
Given (2) in a language you'll often see in a language that functions are first-class data.
Functional programming is just (a set of) best-practices. It's scary when the big words are new. Once you use it a bit you'll wonder why when you say, "use a flatMap", folks freak out because all you've said is, "You are transforming the elements of some container into values that are themselves an instance of the same container but you want to flatten everything back from nested containers. [E.g., Container is C with element type A; thus C[A]. You've run a transform that will create C[C[A]] but want to end up with C[A] at the end]." Now you could say that second part but that's a lot of words. Because of points (2) and (3) above we just say, "use a flatMap" (or however you spell `bind` in your language of choice).
Nothing to see here. Please move along. (And yes. I like functional programming. A lot.)
1) Do you need a degree or to dive into the math to make effective use of the language? No. Like any programming language you can just learn the patterns and apply them. That said, like any programming language, if you learn the math behind why it works you can make more effective use of the language. (You are probably using monoids, functors, monads, and maybe applicative functors in any large program. Not knowing what those are doesn't mean you aren't using them.)
2) Would I recommend switching?
I having been programming professionally for 31 years. I have been programming Scala since 2010. I have taught about a dozen people the language. Much like, "Should I quite my day job to put all my time into my startup?", the answer is probably, "not right now". If you can get the same or better pay, under the same or better conditions, then obviously yes, make the switch. Otherwise if the language interests you (same answer for the startup) then work on it in your spare time with your day job giving you the security you need to expand your horizons. As a programmer learning new languages will make you a better programmer. Learning languages like Scala or Haskell which lean so heavily into functional programming and their higher-kinded type systems will definitely expand your knowledge. Additionally you'll then be able to decide if a switch is worth it FOR YOU rather than relying on getting a useful answer from a infinite number of monkeys banging on an infinite number of keyboards.
All that said no company would pay the price I would demand to code in Java again.
Being in the middle of taking a Coursera course right now I can state that the content is still free if you audit the course. Auditing a course gives you access to the lectures, coursework, and the forums. You cannot submit coursework for a grade, nor receive a final grade and certificate (if you pass) unless you have paid for the course.
Having taken several of the original free courses I was concerned at first but once I read through all the fine print I think it's a fine way to monetize the system. Free for those that want information and a charge for those that want proof of having taken the course.
This again. Every language is poor if used poorly. Every technology is poor if used poorly. And the opposite is also true. The trick to getting good technology if used correctly is that some technologies require more discipline on the part of the developer/implementer to use well.
In my company we aggressively mentor everyone so the language (Scala) doesn't have a lot of dark corners. We also mentor the mathematics (I see monoids. They're everywhere!) so that when someone comes across a bit of advanced code almost indistinguishable from magic they don't think "it's magic. I can't touch it." It takes an extra dozen weeks or so but the return is huge (like taking a couple of thousand lines of code and turning it into 80, all nicely immutable to kill those nasty action-at-a-distance bugs).
There's nothing wrong with Perl that isn't also wrong with every other language. They are a tool. If you choose not to learn how to use a tool appropriately don't make the mistake of thinking the tools you know how to use well are intrinsically better.
I would never describe Perl as boring. Annoyingly random, and obtuse, but never boring.
First, don't go it alone. If you can't find a few friends that you can convince that you are on to something with whatever product ideas you have then you aren't on to something.
Software development is a team sport. Even if the other players are you in 6 months. Have coding standards. Have have your IDE or some program enforce them. Write documentation. Use version control. Use a bug tracking system. (Yeah, all that stuff you've read is best-practice... it got published as best-practice for a reason.) As a startup select a "major" language but for scripting just accept that any of perl, python, ruby, bash are fine. Train, mentor, and grow your people. You want really good generalists at this stage and not experts that can't also do ops, admin, front-line, etc. Using open-source software is a force multiplier. If you are going to extend OSS just make sure that your product value is in the data you are generating and not the code (since you'll be giving the code away for free).
You'll want to find people at least as good as you are for raising money, marketing, sales, product development, and IT (assuming you'll be CTO/VP Eng and leading development; if not find a CTO [tech strategist to put in front of investors and give you something coherent as far as technology goes], and/or a VP Eng [developer+manager who can wrangle the cats and makes sure product gets delivered when product is supposed to be delivered]. Coming from the tech side of things do NOT undervalue marketing, sales, and your CEO. The better mousetrap will not sell itself. At the same time while a great sales guy can sell snow to Eskimos they won't pay a lot for it. Find/build a team that covers each others weaknesses.
Gonna stop here. Could go on like this for a while since this is what I've been living the past 4 years.
Blogs in no particular order: Joel on Software, Paul Graham, any other 2-3 of the top tech incubators in the country (Google em).
Finally, ignore anything above that doesn't make sense for the business you are running.
It's not being an expert at some particular language that ends up paying. It's being an expert. You will always have to play your cards right but there are high paying jobs in any of the languages. Figure out the style you like, become an expert in one of its mainline languages, play your cards right, profit.
Valid criticism of Scala: full functional programming requires ScalaZ which has nightmare stupid misfeatures like use of Unicode operators
First all the unicode operators of scalaz have names as well. Second, just what language is the functional library scalaz written in? I'll bet *that* would be a pretty good functional language to work with.
It's Scala. They left out pattern matching and didn't drive the monadic nature of common programming collections through the collection classes. You can leave out the monads (although the first time you want to convert the contents of an Optional value via a function returning an Option you'll wish they hadn't) but leaving out pattern matching was a plain and simple misstep.
I guess I did miss the point. Since in my family it was all about how misguided the Vietnam war was and talks of student sit ins and such. Fonda was naive but she was, I think, on the correct side of the argument.
But I guess you missed the point too. Holder stated [1] that the Executive Branch wasn't going to make a blanket statement hemming in the Executive to use drones during such events as Peal Harbor and 9/11. So what we've got is a temper tantrum which compares two of the most epic events in US history where the power of the Executive would have swept pretty much anything before it to a single Vietnam war protester who happened to get a lot of attention because she was a celebrity over whom the Executive could only exert the most minor of authority. If a drone were to have killed Jane Fonda it would have been an obvious criminal action. If a drone had shot down one of the remaining jets after the towers were hit it would have been a justified use of a military force to avoid a larger death toll. Trying to compare the two is simply trying to derail the stated response to (Rand's) original question.
Holder's comment that set off Paul was that he wouldn't rule out a President using drone attacks on US soil during such hypothetical events as those of 7 Dec 1941 and 11 Sep 2001. From there to Jane Fonda. I didn't realize she was such a national treasure.
(Dang. Wish I'd gotten in on this thread earlier because I'm just gonna repeat elements from the best posts.)
Yes I have daily meeting with my team; Monday and Thursday 10-10:20 Mountain.
Yes it's productive. Younger hands call roadblocks and the elders speak up with, "I'll help you on that". Someone's stalled for a couple of weeks or three without calling roadblock and I start to ask about things in our weekly 1-1 (burnout; too proud to ask for help; "Nailing top tier in my guild's PvP rankings but I'll be back in the saddle next week"). Meetings run long with dirt-diving, carping, gossip about execs then my canary just died.
I was a unix sysadmin for six years, manager for three, developer for four and now I'm back in the manager slot. In that time I had a manager that held a daily hour meeting and a project manager that held once weeklies that I would trade my teeth to get as much out of my team as they did out of us but I'm not them and my team isn't the one they worked with and my dailys held twice a week work for me.
Dailys are the answer for everything. (Except when they aren't.)
I envy you then. Our Alamo's food is less than stellar. (West Oaks, Houston.) The special features are very good but the normal menu is straight out of cans and the freezer. Just a touch more effort on their part would go a long way. I'm not expecting miracles but I'd rather not have to stick to the two things on the menu I've found to be... hard to do wrong.
With that mini-rant out of the way I totally agree with you that, in general, they are the way to go for a good evening at the movies. (Other of their locations I've been very happy with the food so I suspect it's a kitchen issue.)
Joel also runs Fog Creek Software. Tell your boss you want this sort of environment http://www.fogcreek.com/about.html since Joel recommends it.
10-11 hour days can be done. I aim for 65 hours a week. They can't be done without extenuating circumstances though when you can just walk on over to the next shop and get the same pay for a standard 8 hour day. Update your resume. It might work out but I'd bet against.
When this happens to me I just imagine my wife and children living under a bridge. It's amazing how motivated I get to grind out the code. Hmm. If you don't like your wife and kids you might check the next post.
Fine. No null references. So I create the same thing by having a reference to some unique structure (probably named Null) and I still *fail to check for it*.
I also am forced in to clearcase. Here's the workflow I use:
ct mkview...
cd/view/VIEW/vob/blah/dir
git init
git add .
git commit -m 'Init'
cd/somewhere/else
git clone/view/VIEW/vob/blah/dir
# do real work rather than fight clearcase
Git plays quite nicely with other systems.
-CZ
PS - Easy enough to write a small script to sync difference back to clearcase or update your clearcase master and merge into your workspace.
But the management stint wasn't wasted. It did make me realize there is a "bigger picture" that is always mentioned. I'd say the most important thing is to get this across. Tell them there will be decisions made by you, sometimes that you have control over and sometimes not, that won't make a lot of sense at your group's level. If they're your decisions you have some hope of explaining them. If they are decisions made up the chain then give as much information as you have and point out that it made sense to someone at some point and since y'all are all getting a paycheck from the same company then those are the marching orders.
Other than that just work to get your team the things they need. It's their work that will make you look good (or bad) so your job is to make sure they have the tools and time they need to do their jobs. If you give them that then they need to actually do their jobs and you will want to keep them accountable for that. Nothing says bad manager more than someone who ignores the slacker while everyone else is pulling their weight.
All the talk on which languages to learn is missing a fundamental point. Computer programming isn't about the language you program in. It's about the data structures you use. If you want to be a good programmer get good at composing and transforming your data. Learn (inside and out) all the basic structures. Keep learning new ones. Not that you'll build them from scratch yourself but you'll know what's going on when you come across one in the wild. Throw in some analysis of algorithms. Sadly I couldn't analyze something these days to save my life but you'll know the stock answers [True story. I once had a (self-taught) programmer reporting to me use a bubble sort for several thousand rows of db extracted data. When I asked why he didn't sort using the database or sort() he replied that he didn't know how those worked internally so wrote the one that he knew.:/] and be able to make educated guesses.
Once you know the structures and some algorithms then learn languages and implement what you already know. You'll pick up new tricks from each language as you go and be able to pull those out in different language settings when you need.
The poster(s) that mentioned learning the business end of software engineering, proposing, designing, herding-the-cats, developing, and not getting stuck in ongoing support (you want to be good enough to always be on the next project and not the guy stuck on phone/case support ten years after the project has been out) hit the nail on the head. There's a lot more of that than there is of coding (or at least it will feel that way). To get good at the above items you'll need to develop those writing, speaking, and presentation skills.
Be sure and learn about revision control systems (and the data structures and algorithms involved:) and comment your code.
All the rest is just putting up with politics large and small.
Don't just thing pretty code makes a nice system. We recently rewrote a large system. While implementing I noticed that when you wanted to add something to the new system the infrastructure was already there and it was easy to conceptualize how to work the new functionality in. In our old system the code almost pushes you away. Trying to extend functionality almost always means a several day long refactor chain or just adding a new wart. I figure going forward the rewrite would pay for itself over the next two to three large requests for additional functionality so of course it got canceled and we were told to work in the old codebase.:/
Anyway my point is there is more to pretty than syntax and layout.
First establish boundries. Our shop (large corporate) handles 40 unix or 80 windows servers per admin. We run about 200 desktops per field tech. I'm not claiming super-man status because we got to where we are by constantly moving to automation and standardization where possible. (Be sure not to standardize to the point where you choke creativity to death though.)
So on establishing boundries go to your management (as a sysadmin team) and say you can't handle the workload. No crime in that because if they don't recognize it you'll be gone in 4-6 months anyway. As a joint sysadmin/management exercise work out what you all agree are reasonable support levels. Get commitment that they'll hire to those levels. If they don't then accept the writing on the wall and leave. (Or don't leave and burn out after that 4-6 months anyway.)
Spend your 40 a week doing work. Take those extra 20 and drive through anything that will automate your shop and let you work with fewer people. If they say, "You have to do more with less", then leave. By definition you can't do more with less. What you can do is ladder-step your environment to where fewer people can do more than before (but note that's not more-with-less. That's more (work) with more (tooling).)
Good luck. And I don't think you appreciate how lucky you are. One day you'll be in a very successful automated shop and be pining for the good-old-days when sysadmins would crawl into a burning office and fix a crashed disk with their teeth and save the day because the sysadmins of today just don't know how easy they have it.
In perl there are references. A reference is created by \ on a container.
my $scalar_ref = \$a_scalar;
my $array_ref = \@an_array;
my $hash_ref = \%a_hash;
or you can create a reference with anonymous array and/or hash syntax.
my $array_ref = [ 1, 2, 3 ];
my $hash_ref = { "a" => 1, "b" => 2 };
A reference can have a namespace associated with it. This is done with bless(). Such a blessed reference is called an "object".
my $obj = bless( {}, 'My::Class' );
Subroutines can be written to work on objects. They expect their first parameter to be the object being worked on. Subroutines that expect an object as their first parameter are called "methods". Often this parameter, by convention, is named $self.
sub do_something {
my $self = shift;
# do something
}
If you use an '->' between an object variable and a subroutine then the parser rewrites this to provide the object as the first argument to the subroutine.
$obj->do_something();
A method call is first searched for in the package the object is blessed into. If it is not found there the package's @ISA array is examined. Each namespace in the @ISA array is searched (while in turn any @ISA's in that namespace is searched if the method is not located in the namespace) until the first method is found or none is.
That's it. Everything else you can put together from general OO techniques.
Here's a small Point class. _init() is seperated from new() so that any sub-classes of Point (those packages that have a @ISA list with 'Point' as an element) can override it without having to rewrite new(). Alternately a sub-class could do some additional work and call $self->SUPER::_init(...) to call _init() in some super class.
package Point; use strict;
sub new {
my $class = shift;
my $self = bless( {}, $class );
PS - I agree with the Salon article. If kids are going to go past BASIC then in time they'll learn its deficiencies. If they aren't then BASIC is as good as anything to play with.
I totally disagree with his contention that it's impossible to find a BASIC interpreter. Heck, he should just write one if he wants it for his son so badly and can't seem to figure out Google.
Slashdot Mirror
Wow. Really?
Functional programming.
1. Prefer non-mutable data. No more action at a distance bugs. Hand off a reference to your data structure and don't have to care. Replay any data transform at any point as a unique structure.
2. Prefer a defined and well known API often involving transforms that take a function as an argument to provide the predicate (e.g., filter), transform (e.g., map), aggregation (e.g., foldLeft/Right), or whatever building block.
3. Prefer data structures that you can reason about based on a well-known set of patterns. (Best quote ever: "You say `patterns' and everyone is warm and fuzzy. You say `monad' and every loses their f-ing minds.)
Given (2) in a language you'll often see in a language that functions are first-class data.
Functional programming is just (a set of) best-practices. It's scary when the big words are new. Once you use it a bit you'll wonder why when you say, "use a flatMap", folks freak out because all you've said is, "You are transforming the elements of some container into values that are themselves an instance of the same container but you want to flatten everything back from nested containers. [E.g., Container is C with element type A; thus C[A]. You've run a transform that will create C[C[A]] but want to end up with C[A] at the end]." Now you could say that second part but that's a lot of words. Because of points (2) and (3) above we just say, "use a flatMap" (or however you spell `bind` in your language of choice).
Nothing to see here. Please move along. (And yes. I like functional programming. A lot.)
1) Do you need a degree or to dive into the math to make effective use of the language? No. Like any programming language you can just learn the patterns and apply them. That said, like any programming language, if you learn the math behind why it works you can make more effective use of the language. (You are probably using monoids, functors, monads, and maybe applicative functors in any large program. Not knowing what those are doesn't mean you aren't using them.)
2) Would I recommend switching?
I having been programming professionally for 31 years. I have been programming Scala since 2010. I have taught about a dozen people the language. Much like, "Should I quite my day job to put all my time into my startup?", the answer is probably, "not right now". If you can get the same or better pay, under the same or better conditions, then obviously yes, make the switch. Otherwise if the language interests you (same answer for the startup) then work on it in your spare time with your day job giving you the security you need to expand your horizons. As a programmer learning new languages will make you a better programmer. Learning languages like Scala or Haskell which lean so heavily into functional programming and their higher-kinded type systems will definitely expand your knowledge. Additionally you'll then be able to decide if a switch is worth it FOR YOU rather than relying on getting a useful answer from a infinite number of monkeys banging on an infinite number of keyboards.
All that said no company would pay the price I would demand to code in Java again.
Being in the middle of taking a Coursera course right now I can state that the content is still free if you audit the course. Auditing a course gives you access to the lectures, coursework, and the forums. You cannot submit coursework for a grade, nor receive a final grade and certificate (if you pass) unless you have paid for the course.
Having taken several of the original free courses I was concerned at first but once I read through all the fine print I think it's a fine way to monetize the system. Free for those that want information and a charge for those that want proof of having taken the course.
This again. Every language is poor if used poorly. Every technology is poor if used poorly. And the opposite is also true. The trick to getting good technology if used correctly is that some technologies require more discipline on the part of the developer/implementer to use well.
In my company we aggressively mentor everyone so the language (Scala) doesn't have a lot of dark corners. We also mentor the mathematics (I see monoids. They're everywhere!) so that when someone comes across a bit of advanced code almost indistinguishable from magic they don't think "it's magic. I can't touch it." It takes an extra dozen weeks or so but the return is huge (like taking a couple of thousand lines of code and turning it into 80, all nicely immutable to kill those nasty action-at-a-distance bugs).
There's nothing wrong with Perl that isn't also wrong with every other language. They are a tool. If you choose not to learn how to use a tool appropriately don't make the mistake of thinking the tools you know how to use well are intrinsically better.
I would never describe Perl as boring. Annoyingly random, and obtuse, but never boring.
First, don't go it alone. If you can't find a few friends that you can convince that you are on to something with whatever product ideas you have then you aren't on to something.
Software development is a team sport. Even if the other players are you in 6 months. Have coding standards. Have have your IDE or some program enforce them. Write documentation. Use version control. Use a bug tracking system. (Yeah, all that stuff you've read is best-practice... it got published as best-practice for a reason.) As a startup select a "major" language but for scripting just accept that any of perl, python, ruby, bash are fine. Train, mentor, and grow your people. You want really good generalists at this stage and not experts that can't also do ops, admin, front-line, etc. Using open-source software is a force multiplier. If you are going to extend OSS just make sure that your product value is in the data you are generating and not the code (since you'll be giving the code away for free).
You'll want to find people at least as good as you are for raising money, marketing, sales, product development, and IT (assuming you'll be CTO/VP Eng and leading development; if not find a CTO [tech strategist to put in front of investors and give you something coherent as far as technology goes], and/or a VP Eng [developer+manager who can wrangle the cats and makes sure product gets delivered when product is supposed to be delivered]. Coming from the tech side of things do NOT undervalue marketing, sales, and your CEO. The better mousetrap will not sell itself. At the same time while a great sales guy can sell snow to Eskimos they won't pay a lot for it. Find/build a team that covers each others weaknesses.
Gonna stop here. Could go on like this for a while since this is what I've been living the past 4 years.
Blogs in no particular order: Joel on Software, Paul Graham, any other 2-3 of the top tech incubators in the country (Google em).
Finally, ignore anything above that doesn't make sense for the business you are running.
It's not being an expert at some particular language that ends up paying. It's being an expert. You will always have to play your cards right but there are high paying jobs in any of the languages. Figure out the style you like, become an expert in one of its mainline languages, play your cards right, profit.
Valid criticism of Scala: full functional programming requires ScalaZ which has nightmare stupid misfeatures like use of Unicode operators
First all the unicode operators of scalaz have names as well. Second, just what language is the functional library scalaz written in? I'll bet *that* would be a pretty good functional language to work with.
It's Scala. They left out pattern matching and didn't drive the monadic nature of common programming collections through the collection classes. You can leave out the monads (although the first time you want to convert the contents of an Optional value via a function returning an Option you'll wish they hadn't) but leaving out pattern matching was a plain and simple misstep.
I guess I did miss the point. Since in my family it was all about how misguided the Vietnam war was and talks of student sit ins and such. Fonda was naive but she was, I think, on the correct side of the argument.
But I guess you missed the point too. Holder stated [1] that the Executive Branch wasn't going to make a blanket statement hemming in the Executive to use drones during such events as Peal Harbor and 9/11. So what we've got is a temper tantrum which compares two of the most epic events in US history where the power of the Executive would have swept pretty much anything before it to a single Vietnam war protester who happened to get a lot of attention because she was a celebrity over whom the Executive could only exert the most minor of authority. If a drone were to have killed Jane Fonda it would have been an obvious criminal action. If a drone had shot down one of the remaining jets after the towers were hit it would have been a justified use of a military force to avoid a larger death toll. Trying to compare the two is simply trying to derail the stated response to (Rand's) original question.
[1] http://paul.senate.gov/files/documents/BrennanHolderResponse.pdf
Holder's comment that set off Paul was that he wouldn't rule out a President using drone attacks on US soil during such hypothetical events as those of 7 Dec 1941 and 11 Sep 2001. From there to Jane Fonda. I didn't realize she was such a national treasure.
Have the drones on the border only been going after sub-humans?
(Dang. Wish I'd gotten in on this thread earlier because I'm just gonna repeat elements from the best posts.)
Yes I have daily meeting with my team; Monday and Thursday 10-10:20 Mountain.
Yes it's productive. Younger hands call roadblocks and the elders speak up with, "I'll help you on that".
Someone's stalled for a couple of weeks or three without calling roadblock and I start to ask about things in our weekly 1-1 (burnout; too proud to ask for help; "Nailing top tier in my guild's PvP rankings but I'll be back in the saddle next week").
Meetings run long with dirt-diving, carping, gossip about execs then my canary just died.
I was a unix sysadmin for six years, manager for three, developer for four and now I'm back in the manager slot. In that time I had a manager that held a daily hour meeting and a project manager that held once weeklies that I would trade my teeth to get as much out of my team as they did out of us but I'm not them and my team isn't the one they worked with and my dailys held twice a week work for me.
Dailys are the answer for everything. (Except when they aren't.)
-CZ
I envy you then. Our Alamo's food is less than stellar. (West Oaks, Houston.) The special features are very good but the normal menu is straight out of cans and the freezer. Just a touch more effort on their part would go a long way. I'm not expecting miracles but I'd rather not have to stick to the two things on the menu I've found to be... hard to do wrong.
With that mini-rant out of the way I totally agree with you that, in general, they are the way to go for a good evening at the movies. (Other of their locations I've been very happy with the food so I suspect it's a kitchen issue.)
0.02USD
Joel also runs Fog Creek Software. Tell your boss you want this sort of environment http://www.fogcreek.com/about.html since Joel recommends it.
10-11 hour days can be done. I aim for 65 hours a week. They can't be done without extenuating circumstances though when you can just walk on over to the next shop and get the same pay for a standard 8 hour day. Update your resume. It might work out but I'd bet against.
-CZ
Just encrypt your email. You'll get the noticed desired when the warrant is served for your encryption keys.
-CZ
When this happens to me I just imagine my wife and children living under a bridge. It's amazing how motivated I get to grind out the code. Hmm. If you don't like your wife and kids you might check the next post.
-CZ
Fine. No null references. So I create the same thing by having a reference to some unique structure (probably named Null) and I still *fail to check for it*.
Null references don't kill programs. Programmers do.
-CZ
I also am forced in to clearcase. Here's the workflow I use:
ct mkview ... /view/VIEW/vob/blah/dir /somewhere/else /view/VIEW/vob/blah/dir
cd
git init
git add .
git commit -m 'Init'
cd
git clone
# do real work rather than fight clearcase
Git plays quite nicely with other systems.
-CZ
PS - Easy enough to write a small script to sync difference back to clearcase or update your clearcase master and merge into your workspace.
Went back to the tech side.
But the management stint wasn't wasted. It did make me realize there is a "bigger picture" that is always mentioned. I'd say the most important thing is to get this across. Tell them there will be decisions made by you, sometimes that you have control over and sometimes not, that won't make a lot of sense at your group's level. If they're your decisions you have some hope of explaining them. If they are decisions made up the chain then give as much information as you have and point out that it made sense to someone at some point and since y'all are all getting a paycheck from the same company then those are the marching orders.
Other than that just work to get your team the things they need. It's their work that will make you look good (or bad) so your job is to make sure they have the tools and time they need to do their jobs. If you give them that then they need to actually do their jobs and you will want to keep them accountable for that. Nothing says bad manager more than someone who ignores the slacker while everyone else is pulling their weight.
$0.02,
-CZ
Seconded. (But anything with actual lumbar support will work.)
-CZ
All the talk on which languages to learn is missing a fundamental point. Computer programming isn't about the language you program in. It's about the data structures you use. If you want to be a good programmer get good at composing and transforming your data. Learn (inside and out) all the basic structures. Keep learning new ones. Not that you'll build them from scratch yourself but you'll know what's going on when you come across one in the wild. Throw in some analysis of algorithms. Sadly I couldn't analyze something these days to save my life but you'll know the stock answers [True story. I once had a (self-taught) programmer reporting to me use a bubble sort for several thousand rows of db extracted data. When I asked why he didn't sort using the database or sort() he replied that he didn't know how those worked internally so wrote the one that he knew. :/] and be able to make educated guesses.
:) and comment your code.
Once you know the structures and some algorithms then learn languages and implement what you already know. You'll pick up new tricks from each language as you go and be able to pull those out in different language settings when you need.
The poster(s) that mentioned learning the business end of software engineering, proposing, designing, herding-the-cats, developing, and not getting stuck in ongoing support (you want to be good enough to always be on the next project and not the guy stuck on phone/case support ten years after the project has been out) hit the nail on the head. There's a lot more of that than there is of coding (or at least it will feel that way). To get good at the above items you'll need to develop those writing, speaking, and presentation skills.
Be sure and learn about revision control systems (and the data structures and algorithms involved
All the rest is just putting up with politics large and small.
-CZ
Don't just thing pretty code makes a nice system. We recently rewrote a large system. While implementing I noticed that when you wanted to add something to the new system the infrastructure was already there and it was easy to conceptualize how to work the new functionality in. In our old system the code almost pushes you away. Trying to extend functionality almost always means a several day long refactor chain or just adding a new wart. I figure going forward the rewrite would pay for itself over the next two to three large requests for additional functionality so of course it got canceled and we were told to work in the old codebase. :/
Anyway my point is there is more to pretty than syntax and layout.
-CZ
First establish boundries. Our shop (large corporate) handles 40 unix or 80 windows servers per admin. We run about 200 desktops per field tech. I'm not claiming super-man status because we got to where we are by constantly moving to automation and standardization where possible. (Be sure not to standardize to the point where you choke creativity to death though.)
So on establishing boundries go to your management (as a sysadmin team) and say you can't handle the workload. No crime in that because if they don't recognize it you'll be gone in 4-6 months anyway. As a joint sysadmin/management exercise work out what you all agree are reasonable support levels. Get commitment that they'll hire to those levels. If they don't then accept the writing on the wall and leave. (Or don't leave and burn out after that 4-6 months anyway.)
Spend your 40 a week doing work. Take those extra 20 and drive through anything that will automate your shop and let you work with fewer people. If they say, "You have to do more with less", then leave. By definition you can't do more with less. What you can do is ladder-step your environment to where fewer people can do more than before (but note that's not more-with-less. That's more (work) with more (tooling).)
Good luck. And I don't think you appreciate how lucky you are. One day you'll be in a very successful automated shop and be pining for the good-old-days when sysadmins would crawl into a burning office and fix a crashed disk with their teeth and save the day because the sysadmins of today just don't know how easy they have it.
Cheers,
-CZ
In perl there are references. A reference is created by \ on a container.or you can create a reference with anonymous array and/or hash syntax.A reference can have a namespace associated with it. This is done with bless(). Such a blessed reference is called an "object".Subroutines can be written to work on objects. They expect their first parameter to be the object being worked on. Subroutines that expect an object as their first parameter are called "methods". Often this parameter, by convention, is named $self.If you use an '->' between an object variable and a subroutine then the parser rewrites this to provide the object as the first argument to the subroutine.A method call is first searched for in the package the object is blessed into. If it is not found there the package's @ISA array is examined. Each namespace in the @ISA array is searched (while in turn any @ISA's in that namespace is searched if the method is not located in the namespace) until the first method is found or none is.
That's it. Everything else you can put together from general OO techniques.
Here's a small Point class. _init() is seperated from new() so that any sub-classes of Point (those packages that have a @ISA list with 'Point' as an element) can override it without having to rewrite new(). Alternately a sub-class could do some additional work and call $self->SUPER::_init(...) to call _init() in some super class.
10 query="BASIC freeware"
20 google $query
30 end
-CZ
PS - I agree with the Salon article. If kids are going to go past
BASIC then in time they'll learn its deficiencies. If they aren't
then BASIC is as good as anything to play with.
I totally disagree with his contention that it's impossible to find
a BASIC interpreter. Heck, he should just write one if he wants it
for his son so badly and can't seem to figure out Google.