Well, theres growing and then theres growing fast enough.
Unless your working for the next yahoo, chances are within 2 years of starting, your going to be looking around seeing positions at your experience level that pay more than your company is going to be able to pay you within the reasonable future.
Working small companies, at least from what i`ve seen, you generally have to change companies every few years. This isn't necessarily bad, but it kind of sucks to just get settled into a place and have to leave to advance your career.
As for becoming a CTO... if I wanted to do that I would have gone into business administration.
Ultimately though, if you've found a small company thats growing fast enough to keep up with your career and doesn't have a paper thin budget that would topple if one major contract was killed... go for it. Sounds like the best of both worlds.
I find that while smaller companies can have some major advantages, they also have some major disadvantages.
Probably the biggest disadvantage in my opinion is the lack of opportunity for advancement. If you _are_ the software development department... there really isn't a whole lot of room for career growth.
And while some people list bureaucracy and excessive policies as one of the major disadvantages of a larger company, I find that sometimes having a standard method of doing everything kind of comforting. In a smaller company, applying for an increase in pay tends to be an awkward, nerve wracking experience.. in a larger company, there is usually some kind of application process or annual performance review in which to bring it up.
Further, and I suppose this really depends on what you do at your company, but working at a larger company can provide a bit of comfort from knowing that you are just a small cog that at worst is going to slow down the machine a little. If you are the only programmer in a small 5 person operation, and they are depending on you to make a deadline lest they loose _the_ contract and go bankrupt (costing 4 people their jobs)... that can put a little pressure on you.
This all being said, most of those points have an inverse advantage. Ie. being a small cog means that you don`t usually get a lot of say in what happens. Being _the_ cog can be really nice, because you pretty much have free reign in how you do things in your little corner of the office.
Ultimately I think everyone should try to experience both environments at some point in their career.
I was forced to live without my gadgets for a while back in 2003 when hurricane Juan knocked out the power for 2 weeks... and it really.. really sucked.
I have always accepted that I'm obsessed with technology (a programmer by trade, it kind of comes with the business).. but it didn't occur to me that I'm literally addicted. Reflecting, I realized that I rely on some form of technology for almost all sources of entertainment. The first few days were not all that bad, in fact, they were kind of interesting. The storm had not done any damage to our house, we had plenty of food, it was just like an extended blackout. But then boredom set in, and within a week I was going out of my mind.
It didn't help that the electric company played games with our minds. They came by about a week and a half in and fixed the power on ONE HALF (not the half we live on) of our street. Turns out we are actually fed by a different set of lines. I'm out there talking with my neighbors, and we're like... "there coming back right... RIGHT??!!??!!".
But do I think theres a problem with any of this? No, not really. I'll admit, if someone dropped me off on some deserted island, I probably wouldn't last long. But I don`t really think dependence on technology is a problem... as long as one insures he always has an adequate supply *pats generator*.
I'm not an vim eletist or anything, I've just never really extensively tried emacs.
I don`t really have anything against it, but for some reason have just never been able to find the time to learn it. It's on my list `o things to do some day;)
I seem to frequently shift between tools of choice on *nix. They all have their flaws, and all have their advantages, each of which becomes more or less relevant depending on what your working on. I find that:
Eclipse absolutely rules for working on a system dealing with multiple languages and database environments.It's perspective system is genius in my opinion, as it lets you easily switch from one "environment" to the next without having to close your work, and also lets you merge environments (ie. be working on a C++ source file with the database info in the side/bottom bars. It's major flaw though, in my opinion, is that it's too resource intensive. Even on a reasonably powerful machine, it tends to feel laggy. It also seems to have a few quarks due to its Java-ness.
Vim, well, like all *nix geeks I love vim. It's only real shortcoming in my opinion is when dealing with many source files, and while gvim supports tabs.. it's still clunky and awkward compared to most other GUI tools.
On that note, I am kind of warming to gvim lately. I used to scoff at it, but after forcing myself to try it, I am actually finding it fairly nice. Still feels like a cli app hacked to run in a GUI shell, but it doesn`t seem to take anything away from the vim experience.
Code::Blocks would be awesome, if it was a little more stable, and like eclipse, a little less bloated.
Anjuta.. well.. I didn't mind it, but I found its insistence that you do everything through its project management facilities a little annoying. I don't mind editors having project management features, but they shouldn't force their use.
gedit is fairly nice, although it's syntax highlighting is a little wonky (especially when it comes to things like treating apostrophes as single quotes...)
nedit is nice, but it suffers from the same wonky syntax highlighting issues gedit does.
kdevelop is in my opinion just plain overkill. If your working on a huge project it might be nice, but for a medium to small project, its just insane. Also feels very laggy.
In short, I don`t think there will ever be a perfect editor. Most developers are like me, that is, opinionated and picky. Little things will put us off an entire tool set.
My perfect editor would probably be an mix of vim and eclipse (less the bloat). But some people would want more vim, and some people would want more eclipse... and trying to make it customizable with plugins and massive sets of options is probably what contributes a lot of eclipses bloat (besides the Java).
I agree fully.
Thats actually what we are doing now. We use Trac to manage our project (and it's documentation) and it has worked out fairly well.
We tend to put comments in the code to document specific sections, and use Trac's wiki to further explain things/provide general overview documentation.
Ugly code is really unavoidable. It's going to happen. While you should always try to write good, clean, maintainable code, circumstances can conspire against you. Project requirements can change half way through development with a timeline that doesn`t allow for going back and changing code properly. And of course there are always people who have ample time to write good code, but just don`t know how/don`t care.
After having worked on what I could only describe as some of the ugliest code on the face of the earth (written by people who previously made a living writing throw away code for PhD types (the kind of code that you use to find an answer, then never use again)) I would say the _real_ problem that makes one want to just go hang themselves in the server room with some cat5 is lack of documentation.
Nothing compounds poorly written code as much as poor (or non-existent over here) documentation. If you _have_ to hack code to make something work in a hurry... COMMENT THE CRAP OUT OF IT. Put a huge comment block, with asterisks and exclamation points and a link to the page in your projects documentation manager describing why you did it, what should be done down the road when time allows, and an apology note to the next guy who has to work on the code.
I have used both, and what I`ve found to be the real difference between Windows MCE and MythTV (and really all the FOSS HTPC types) is tha MCE is simple, straight forward, and just works but is very inflexible (as said in the article, it's hard to even modify the menu, try doing something like having an extra button on you're remote control change the screen font) whereas MythTV requires a little tinkering to get running, but is very flexible.
I think this is really what it comes down to with most Windows VS. FOSS situations. Windows apps tend to work well and are more intuitive, whereas FOSS apps tend to require a little tweaking, but provide more opportunity for customization.
So in short, if you're someone (like me) who likes to have everything just right and doesn't mind messing around for a few days in config files, go with MythTV. If on the other hand you're someone who doesn't mind the canned generic MCE look and feel, and wants something thats just going to work, go with MCE.
In Sofia's case, her parents' plan included only 100 free text messages a month -- fewer than half of what she was using every day "at all points of the day" Thats 200 a day?
So we're talking a text message every ~8 minutes.. IF SHE DIDN'T SLEEP!
I think it's worth noting that it costs a _fortune_ to route calls through a satallite. If the airlines are making a profit from air phones, its a very thin one.
(Insert conspiracy theory "they just want you to think it costs a fortune to route satallite calls" here)
Slashdot Mirror
This combined with that Faraday paint stuff they sell could probably make a decently radio-quiet home, albeit expensive.
Great.. and just when we were starting to look at alternative fuel
I believe we call that NAS
So we can live in constant fear of the top breaking and the whole thing wrapping around the earth several times!
Well, theres growing and then theres growing fast enough.
Unless your working for the next yahoo, chances are within 2 years of starting, your going to be looking around seeing positions at your experience level that pay more than your company is going to be able to pay you within the reasonable future.
Working small companies, at least from what i`ve seen, you generally have to change companies every few years. This isn't necessarily bad, but it kind of sucks to just get settled into a place and have to leave to advance your career.
As for becoming a CTO... if I wanted to do that I would have gone into business administration.
Ultimately though, if you've found a small company thats growing fast enough to keep up with your career and doesn't have a paper thin budget that would topple if one major contract was killed... go for it. Sounds like the best of both worlds.
I find that while smaller companies can have some major advantages, they also have some major disadvantages.
Probably the biggest disadvantage in my opinion is the lack of opportunity for advancement. If you _are_ the software development department... there really isn't a whole lot of room for career growth.
And while some people list bureaucracy and excessive policies as one of the major disadvantages of a larger company, I find that sometimes having a standard method of doing everything kind of comforting. In a smaller company, applying for an increase in pay tends to be an awkward, nerve wracking experience.. in a larger company, there is usually some kind of application process or annual performance review in which to bring it up.
Further, and I suppose this really depends on what you do at your company, but working at a larger company can provide a bit of comfort from knowing that you are just a small cog that at worst is going to slow down the machine a little. If you are the only programmer in a small 5 person operation, and they are depending on you to make a deadline lest they loose _the_ contract and go bankrupt (costing 4 people their jobs)... that can put a little pressure on you.
This all being said, most of those points have an inverse advantage. Ie. being a small cog means that you don`t usually get a lot of say in what happens. Being _the_ cog can be really nice, because you pretty much have free reign in how you do things in your little corner of the office.
Ultimately I think everyone should try to experience both environments at some point in their career.
I was forced to live without my gadgets for a while back in 2003 when hurricane Juan knocked out the power for 2 weeks... and it really.. really sucked.
I have always accepted that I'm obsessed with technology (a programmer by trade, it kind of comes with the business).. but it didn't occur to me that I'm literally addicted. Reflecting, I realized that I rely on some form of technology for almost all sources of entertainment. The first few days were not all that bad, in fact, they were kind of interesting. The storm had not done any damage to our house, we had plenty of food, it was just like an extended blackout. But then boredom set in, and within a week I was going out of my mind.
It didn't help that the electric company played games with our minds. They came by about a week and a half in and fixed the power on ONE HALF (not the half we live on) of our street. Turns out we are actually fed by a different set of lines. I'm out there talking with my neighbors, and we're like... "there coming back right... RIGHT??!!??!!".
But do I think theres a problem with any of this? No, not really. I'll admit, if someone dropped me off on some deserted island, I probably wouldn't last long. But I don`t really think dependence on technology is a problem... as long as one insures he always has an adequate supply *pats generator*.
I'm not an vim eletist or anything, I've just never really extensively tried emacs.
;)
I don`t really have anything against it, but for some reason have just never been able to find the time to learn it. It's on my list `o things to do some day
I seem to frequently shift between tools of choice on *nix. They all have their flaws, and all have their advantages, each of which becomes more or less relevant depending on what your working on. I find that:
Eclipse absolutely rules for working on a system dealing with multiple languages and database environments.It's perspective system is genius in my opinion, as it lets you easily switch from one "environment" to the next without having to close your work, and also lets you merge environments (ie. be working on a C++ source file with the database info in the side/bottom bars. It's major flaw though, in my opinion, is that it's too resource intensive. Even on a reasonably powerful machine, it tends to feel laggy. It also seems to have a few quarks due to its Java-ness.
Vim, well, like all *nix geeks I love vim. It's only real shortcoming in my opinion is when dealing with many source files, and while gvim supports tabs.. it's still clunky and awkward compared to most other GUI tools.
On that note, I am kind of warming to gvim lately. I used to scoff at it, but after forcing myself to try it, I am actually finding it fairly nice. Still feels like a cli app hacked to run in a GUI shell, but it doesn`t seem to take anything away from the vim experience.
Code::Blocks would be awesome, if it was a little more stable, and like eclipse, a little less bloated.
Anjuta.. well.. I didn't mind it, but I found its insistence that you do everything through its project management facilities a little annoying. I don't mind editors having project management features, but they shouldn't force their use.
gedit is fairly nice, although it's syntax highlighting is a little wonky (especially when it comes to things like treating apostrophes as single quotes...)
nedit is nice, but it suffers from the same wonky syntax highlighting issues gedit does.
kdevelop is in my opinion just plain overkill. If your working on a huge project it might be nice, but for a medium to small project, its just insane. Also feels very laggy.
In short, I don`t think there will ever be a perfect editor. Most developers are like me, that is, opinionated and picky. Little things will put us off an entire tool set.
My perfect editor would probably be an mix of vim and eclipse (less the bloat). But some people would want more vim, and some people would want more eclipse... and trying to make it customizable with plugins and massive sets of options is probably what contributes a lot of eclipses bloat (besides the Java).
I agree fully. Thats actually what we are doing now. We use Trac to manage our project (and it's documentation) and it has worked out fairly well. We tend to put comments in the code to document specific sections, and use Trac's wiki to further explain things/provide general overview documentation.
Ugly code is really unavoidable. It's going to happen. While you should always try to write good, clean, maintainable code, circumstances can conspire against you. Project requirements can change half way through development with a timeline that doesn`t allow for going back and changing code properly. And of course there are always people who have ample time to write good code, but just don`t know how/don`t care.
After having worked on what I could only describe as some of the ugliest code on the face of the earth (written by people who previously made a living writing throw away code for PhD types (the kind of code that you use to find an answer, then never use again)) I would say the _real_ problem that makes one want to just go hang themselves in the server room with some cat5 is lack of documentation.
Nothing compounds poorly written code as much as poor (or non-existent over here) documentation. If you _have_ to hack code to make something work in a hurry... COMMENT THE CRAP OUT OF IT. Put a huge comment block, with asterisks and exclamation points and a link to the page in your projects documentation manager describing why you did it, what should be done down the road when time allows, and an apology note to the next guy who has to work on the code.
I have used both, and what I`ve found to be the real difference between Windows MCE and MythTV (and really all the FOSS HTPC types) is tha MCE is simple, straight forward, and just works but is very inflexible (as said in the article, it's hard to even modify the menu, try doing something like having an extra button on you're remote control change the screen font) whereas MythTV requires a little tinkering to get running, but is very flexible. I think this is really what it comes down to with most Windows VS. FOSS situations. Windows apps tend to work well and are more intuitive, whereas FOSS apps tend to require a little tweaking, but provide more opportunity for customization. So in short, if you're someone (like me) who likes to have everything just right and doesn't mind messing around for a few days in config files, go with MythTV. If on the other hand you're someone who doesn't mind the canned generic MCE look and feel, and wants something thats just going to work, go with MCE.
I think it's worth noting that it costs a _fortune_ to route calls through a satallite. If the airlines are making a profit from air phones, its a very thin one. (Insert conspiracy theory "they just want you to think it costs a fortune to route satallite calls" here)