Your question is lacking quite a bit of context. You haven't for example mentioned how much experience you have with the language, how much programming experience you have in general and other useful things such as what you are using Java for.
Now for recommendations there are a lot of directions that you can go:
* for one the language has a lot of features that all the fancy frameworks use, you should know these so you don't end up using some blown up solution when all you needed was a simple servlet. This would include things like: collections, generics, annotations, enums, concurrency, IO & NIO, JAXP, sockets, servlets, JSP.
This part is pretty heavily covered in Bruce Eckel's "Thinking in Java". Not the easiest read, but definitely a very complete language reference. Servlets & JSP are pretty well covered in "Head First Servlets & JSP".
* another point to consider are general practices that transcend language such as coding practices, design patterns and testing.
You already mentioned "Effective Java", which would be the first one I would recommend in this category.
A very good book about coding practices based in the Java world would be "Clean Code" by Robert Martin. "Head First Design patterns" are very easy to digest, while the "Design pattern" book by the GoF is heavier reading. For testing I would definitely recommend you have a look at "Growing object oriented software guided by tests".
* depending on your field of work you might or might not be interested in Java memory stuff. This includes things like how and where objects are kept in memory, gc algorithms etc.
* finally, and in my opinion the lowest return of investment you could get, is by going for some framework. Not that this is bad, but generally frameworks tend to have shorter lifespans than the language itself and they usually change between projects so all your new Spring chops might not help you on your following project that uses EJB.
I'm not going to recommend anything here, since this is a very fuzzy topic and it depends on the problems you are tackling.
I will have to disagree on this, this advice is only good if your sole purpose is to make a quick buck. If you want to start a long term solid business than I suggest you treat people like humans and not like cheap interchangeable pieces as this post suggests.
Think of it this way, since you are not the one developing the application how much will you know about all its inner workings? When you will have customers and a critical bug in production who will solve it?
If you intend to outsource it I will suggest that you do not look for a cheap quick hack, but rather look for a freelancer with a decent rate, with whom you can build a working professional relationship. You want someone that will stick around for the long run and take responsibility for the software he develops, since building it is just the first step.
I agree that I should be looking for people who produce quality work, but I also think there's some flexibility to the 'interchangeable pieces' part of the argument.
Here's the thing: Building anything ends up being a very iterative process. From my personal experience, by the time one moves from the prototype/beta phase upwards of 90% of the original code/design base is thrown away, redone, etc. Since what I'm really looking for here is the first-cut that allows for the validation of the idea and the on-boarding of the first few (hundred-)thousand users, I think there could be some advantages to a little shorter-term thinking; if-and-only-if that means I'm able to deliver that first cut to market sooner than if I were to focus on the stability of the team upfront.
Don't get me wrong, I'm still wavering on my opinion of this (hence this entire thread). But I am really enjoying / appreciating the various methodologies.
I guess our experiences might vary with what happens to prototypes/first cut implementations.
From my experience what starts off as a simple proof of concept/prototype that is done quick and dirty to validate an idea, ends up being the actual production code. This is due in part to clients that come and say: "well it works, why rewrite it? you can just fix bugs if they come up", making you have to maintain what was originally meant to be a throw away implementation.
While right now your intentions might be to rewrite, I do believe that you might reconsider this decision once you have a couple hundred users to please, who all want new features or bugs fixed. Now I do not know what your idea is and how critical time to market is for you but I would recommend that you consider removing non-essential features to get it out quicker rather than skipping quality.
Who says you have to treat these freelancers "sub-human"? On the contrary, once I find someone that works well with me, I create long-term relationships and treat them with utmost respect. I have a 9+ year working relationship with one of my developers, and even gave a 50% ownership in one of my startups to him. I consider him a really close friend even though we've never met in person.
I have to agree here, transparency is key, trust is a very important part of human relations. You build this by starting with a couple of tasks where you pay the subcontractors hourly rate, to feel each other out, but you need to make sure you are clear about what you want after that: project based work, help on various tasks with an hourly pay model etc.
Since good subcontractors are hard to find you should not treat them as interchangeable pieces and try to get the lowest rate possible. Being transparent will go a long way towards building a professional relationship that will allow you to collaborate long term on multiple projects.
On this note, I would be interested in hearing what you are looking for as I would enjoy doing some subcontracting considering I do not really enjoy the whole client dance. You can find my e-mail in my profile.
Very interesting read. I have to admit that I have been guilty of this self handicaping on more than one occasion. The self illusion of being able to achieve great things if you just put in the time is very difficult to overcome. To me I believe that the difficulty comes from a mix of complacence & fear of discomfort.
One thing that still bugs me to this day, is why this types of issues seem to be more prevalent in the software industry than anywhere else. Has anyone have an idea as to why this is?
I would say it is due to the fact that computers are full of wondrous things that distract us. How many software people have fought game addictions to gloriously complex and involved game? There are more distractions being created than there is time in the day to enjoy and when you feel tired it's so easy to just access that push button entertainment.
As some of the people in this thread have already suggested, the idea of taking a gap year is all about having a plan/purpose. Taking a year off just for the sake of it, is not worth it.
From the way your question is phrased it feels like you want to take a gap year, but don't have a reason yourself. If this is the case the answer is simply put: don't do it.
On the other hand if you have some ideas and want to validate them and see if they are worth it, post them and we can give you feedback on them. This way the discussion would be a lot more constructive.
Moving to contract work is pretty straightforward. It's essentially just finding a new job. Lots of places prefer to hire contractors for individual projects, so it's not too tough to pick up a 3/6/9 month contract someplace.
Most contractors tend to try to move from one contract to the next with as little downtime as possible, or work for an agency that sorts it all out for them. For me, the downtime was the big payoff, since contracting pays roughly double what a salaried job does. If you have no attachments, you can spend a fair amount of time slacking off before picking up another contract. I used to push it as far as 9 months off between 3 month contracts and still put plenty into savings.
Repeat the above enough times, and you'll be able to break off work that doesn't require you to be on site, or pick up work from new clients from word of mouth. Some people refer to this as freelancing, but then they don't get to charge as much if they use that term in front of a client. Naturally, it's best to describe yourself as a consultant instead, and double your rate again.
The transition from full-time to contracting is what terrifies me. Having to constantly look for a new job every few months just worries me. Of course, it's probably because I am the sole breadwinner for my family but how do you overcome that sort of paralyzing fear? I've had thoughts that maybe I will do it later on down the road when everything is more settled but I don't know if things will ever be "settled".
I'm not sure where you're based (and I'd guess it makes a difference), but in the UK going contracting is incredibly easy once you make the decision.
Save up a couple of months salary if you can, make your CV all shiny, and send it out to every job board you can find, with your phone number, email and location at the top. At the same time, send a friendly email and your CV to everyone you've worked with, saying "Hey I'm available for contracts doing X, Y or Z. If you hear about anything, please let me know".
There's no need to quit your job early, you're just going to be leaving like you would for another permanent role.
When someone says they've got a contract for you, sign up for Parasol or a similar umbrella company so paperwork is at a minimum, and away you go!
I'm not hugely experienced at contracting, but since I started doing it a few years ago, another couple of friends have gone down the same route and it's worked out well for them too.
If you're good, learn quickly, and you're honest about what you can do, contracting is a great route for a few years of experience across a range of projects.
After the first couple of contracts, if you're happy with how it's going, then get yourself setup with your own limited company which means you'll end up with more paperwork, but more money in your pocket.
It definitely helps to establish a reputation for yourself before you take off and start contracting. You should be at the point where you know without a doubt that you could send out a few emails (or respond to one of the standing offers in your inbox) and pick up another gig. As such, "paralyzing fear" never came into the equation for me or any of the successful contractors I know.
And of course once you've done it a few times, you'll have previous employers bringing you back in for more projects. So at most you might only need to go through that fear stage a few times before you've established yourself.
> "It definitely helps to establish a reputation for yourself before you take off and start contracting."
Does this mean moonlighting and taking side gigs? If so, can it be done without sacrificing personal/family life? Not to mention, possibly living with exhaustion.
No. Just work for a few different companies and demonstrate that you're the best guy on the team to the people who matter. Eventually you'll get a call from a guy who's putting together a team and got your name from one of your old managers as somebody who's good at that sort of thing.
Of course, it never hurts to build cool, visible things that you can point to when people ask what you're capable of.
Build up savings. The traditional "have 3 months of savings in the bank" line you hear from personal finance gurus doesn't really apply when you're a self-employed breadwinner with a family. I'd suggest a min of 6 months with a goal of 12 months if you can. It will make those in between times much less scary.
Not surprisingly, health insurance isn't that expensive if you only want to cover the 'big' things. It gets worse as you get get older of course.
But if you're healthy, 20 - 30 type, and you're seeing the doctor once or twice a year and maybe using prescription meds occasionally for a bacterial infection, then you get the 'high deductible' plan, you end up paying for that stuff yourself but if you happen to be in a wreck or you get cancer or something the insurance will cover it once you get past your deductible.
as someone who shied away from regular IDEs to use Emacs for programming work, I would recommend that you start setting things up for some very specific need.
As it was already pointed out, Emacs is huge and you will never stop learning it. Therefore, if your main line of work implies writing Java code, I would recommend you look for some tutorials that are particularly aimed at that, and build on those as you need more out of your editor. For example right now I am looking at learning org-mode to be able to do time tracking with it.
If you seriously consider using Emacs all the time I would recommend remapping the Ctrl key to Caps Lock for easier typing.
Since you were asking for some tutorials, these are the two tutorials that I found most useful in defining my Emacs setup:
I am no where near a proficient Emacs user, but maybe I can provide some insight as a fellow learner if you get stuck. I believe my e-mail should be in my profile if you have any problem starting up with Emacs.
This absolutely, best way to learn is to have a specific goal in mind. I got started with emacs because I was using an IDE called RStudio (http://www.rstudio.com/) which I really liked, and I wanted something similar for python but couldn't find anything to suit my needs. I set out to recreate the functionality of RStudio in emacs and have (largely) succeeded. It took a lot of mucking around but I really learned my way around the editor.
Steve Yegge's effective emacs is definitely worth a read. It helped me get used to emacs without contracting RSI :) FWIW, I'm bilingual - I use Vim to write code and emacs to write in English.
I have no intention of stopping. I guess my curiosity was more along the lines of whether it is worth it to dig deeper and learn more Java, or if it would be better to go for some other languages.
I'm also pondering about switching jobs for this, since the best way to learn in my opinion is to force yourself into real projects with new technologies and not just hack on some small projects for a couple of hours each week.
Android is built on Java so learning Android programming is as simple as learning the ins and outs of an Android program rather than a whole new language.
Android won't necessarily increase your market value more than Ruby but it will be a much easier thing to learn considering you already know Java.
This is the exact same feeling that I'm getting from this announcement. To me this just feels like a publicity stunt, where Oracle is aiming to get a slice of the CentOS/RHEL market with very little investment.
As far as I'm concerned this isn't even a valid attempt on their behalf to earn the trust of the Open Source Community. Taking something that already works and touting your own horn about how you can provide faster updates isn't really something that a big corporate player that wants to get into the open source market should be doing. I'm sure there are plenty of technologies at Oracle, that if open-sourced would have a much bigger impact, and would put them in a better relationship with the open source community.
Finally, when you are an enterprise/corporate player, and your press release for a new product is littered with "this is not a gimmick" there is definitely something wrong. In all honesty this just sounds like one of these "come with me kid I'll give you some candy! It's gonna be ok don't worry, just a little further". This is not something I would expect from such a big company.
I was trying to go for a "for linux nerds, by linux nerds" vibe, so I'm amused that your complaint is "This doesn't sound corporate enough".
At the end of the day, my view here is that Oracle has actually produced something useful, but lots of people are blind to it, in no small part because of what ultimately boils down to zealotry (which doesn't seem like an awesome reason to me). Hence the point of trying to get this out there.
I assume you're on the Oracle Linux team? I'm sure you're sincere, and I'm sure the Oracle Linux team has many good folks working on it (likewise, the rest of Oracle). But, when you work within the belly of a beast, an absolute horror show of historic and ongoing wrongdoing, you have to expect pushback and mistrust from the Open Source community.
Oracle is a corporate sociopath. If you wish to label me a zealot for expecting ethics from the people and companies I work with, that's fine. But, it's not going to alter the reality that I am not alone. Many people mistrust Oracle, and just because one unit within Oracle seems to be trying to do right, it doesn't alter the fundamental nature of that creature. It'd be easier to overlook past misdeeds if Oracle was not currently behaving in unethical ways on a massive scale, and attacking Open Source on several fronts.
Oracle cannot have it both ways. It cannot wage war against Open Source and software freedom, and expect the Open Source community to just look the other way and choose Oracle products. At least, I sure as hell won't be looking the other way.
Look, with all due respect we're not blind to it. I'm sure Oracle Linux is a fine piece of software, I bet it's just as good as RHEL and I'll even spot you that your support team is equally good as Red Hat's. We do not have technical objections to the work you've done.
We simply don't trust your employer to behave with anything even approaching good faith in any interaction. What happened to Solaris alone is a huge warning flag, those of us who have interacted with Oracle in a professional capacity have...more reasons to believe this.
No, not FUD...not really. Solaris is a complicated tale.
The short explanation is that when Oracle acquired Sun, all of the hopes and dreams of Solaris users, particularly OpenSolaris users, were dashed. Many great technologies were pushed onto the back burner. All of Sun's Open Source portfolio saw a massive shake up and very little came out the other side healthier. Pre-acquisition, Solaris/OpenSolaris was a reasonable OS choice for new server deployments, particularly in cloud environments. Post-acquisition, you'd have to be a little bit nuts to deploy Solaris. Solaris has a lot of die-hard fans, with good reason...so this was a bitter pill to swallow for a lot of folks.
Oracle is simply ham-fisted when it comes to dealing with Open Source technologies that it comes into possession of. It's a really good example of a company that doesn't "get" Open Source. It's not limited to Solaris, Solaris is just one of the most popular, and the most difficult to replace for people who are relying on it.
I am a long-term SunOS/Solaris user (~20 years) and what killed Solaris is they neglected Solx86 for years for fear of cannibalizing SPARC sales. What happened was devs got Linux boxes to replace SPARCstations (using them as cheap X servers) then x86 and x64 got good enough for servers, and everyone ditched Solaris in order to get onto the commodity hardware (Linux wasn't really a factor in this decision, it just happened to be the dominant Unix on that hardware at the time, could easily have been FreeBSD). Thanks to Microsoft and their NT pretensions, supporting hardware vendors (e.g. storage) were manufacturing compatible kit too. It didn't help that Sun managed to forget that they were a business, and a hardware business at that. Giving stuff away to drive sales is a proven strategy, but no-one was buying SPARCs. Turns out it was cheaper to buy PCs and accept failures and workaround them, than to buy a "real" server that wouldn't fail and if it did, you could hot-swap anything. Call it the Google method.
Sun could have had a compelling desktop-to-datacentre story, all Solaris, on Intel PCs all the way to SPARC near-mainframes. But they succumbed to short term thinking and killed the goose that laid the golden eggs. The alternative to the Oracle acquisition was for them to go the way of SGI...
I'm trying very hard to be as neutral as possible (as opposed to "Oracle bad. Raaaaar!"), but I've been part of the HPC community for a long time, and Oracle has done their best to tell us that we don't matter at all to them (Grid Engine, Lustre, etc.). I understand that the margins on HPC aren't great, so I don't necessarily fault them, but it leaves a very bad taste. That's just one community of many who feel like they've been wronged by Oracle.
You say that they've produced something useful; can you say a little more about what Oracle has specifically produced with respect to Oracle Linux? My strong impression is that they've taken 99.9% Red Hat's hard work, dumped their own 0.1% on top (OCFS2, some IB enhancements, etc.), slapped a big price tag on it and then exclaim, "look what we made!"
Removing that price tag doesn't change much. I'm open to being reasoned with, though, so please tell me why I'm wrong.
There's a ton to talk about in the "Why Oracle Linux and not RHEL" department, but I'm not trying to sell you anything, so I want to set that aside for now. (I have to say, though, even the "big price tag" is significantly smaller than RHEL's).
Instead, I want to look at the following case: you're a sysadmin running CentOS. You don't pay anyone for support, and you have no intention of ever doing so.
There, I think the benefits are, in brief, the things you're able to achieve when you have large-scale resources: timely releases and better QA, while maintaining 100% RHEL compatibility. Basically "what you love about CentOS", minus "what you hate about CentOS".
Useful it may be, but after more than 10 years of having to work with Oracle products and consultants, the first thing that jumped at me was
...doesn't Oracle Linux cost money? A: Oracle Linux support costs money
That "support" word, right there, is the thing that makes me stay as far from Oracle as I can. It's like "Dude, here's the software. Have it, it's cheap/free." When things go wrong you get stung for exorbitant support/consulting fees, because, hey, you're tied in. With nowhere to go.
Sadly, too many organisations still go by the mantra of "The answer is Oracle. Now, what's the question?". That's no basis for a business case.
And yes, this is a rant, and I do have an axe to grind. I'm sorry if that offends (not my intent).
I'm totally with you on fear of lockin, but for what it's worth, this particular case is basically the opposite of lock-in.
You can, at any time, switch away to CentOS, Scientific Linux, or Red Hat (if you're willing to write the check) and not have to totally reinvent your stack from scratch, since they're all binary-compatible.
Your plug for faster updates, for example: Security updates for Solaris used to be free.
So while I know that Oracle is large enough to host many different philosophies in many different departments, what Oracle has done to the former Sun departments really makes me wary of trusting any free offers by Oracle.
Exactly right. I know of several mid- and large-scale companies that replaced (or are replacing) all of their Sun Solaris infrastructure as soon as they heard Oracle acquired them, because of their bad experiences with Oracle.
And from a technical perspective, if the OS is managed anything like the database or client tools, I wouldn't touch it with a 1000ft pole.
I think you did a good job with the vibe, although it was somewhat odd-feeling coming from an oracle.com site.
It did make me double-check the URL bar with the "If you find yourself needing to buy support, have fun reinstalling your system with RHEL before anyone will talk to you". But is perfectly valid.
The problem with Oracle Linux is that it's from Oracle. And I just don't trust them at all. I know I can revert back to CentOS or SL or whatever, but that's a pain. Trust is the problem.
You have a steep hill to hike, but it sounds like you may be cut out to take that on.
I agree, I didn't see anything wrong with the press release. The negative comments here are based on Oracle's long-term reputation. In the wake of the Sun acquisition, they've publicly mismanaged (Hudson) or outright destroyed (OpenSolaris) open-source communities.
I think it's going to take a lot of work for Oracle brand to gain any trust in the eyes of Linux nerds.
You did a good job of the "for linux nerds, by linux nerds" thing. However, when you work for Oracle writing as a linux nerd just comes off as insincere. Your employer is actively working to hurt the linux community, and your continued employment implies your consent of their actions. Your target market needs to be other evil companies that don't care what Oracle does in the courtroom, not linux nerds. "Our product is good" is not a sales pitch that matters right now, because we don't care about your product. It may technologically be the best product for my use case, but that is irrelevant if i don't trust the company behind it. You can call it zealotry if you want, i call it trust and pragmatism. I'm not going to build a business on top of a product that might be used next week as a tool to sue me or my friends. This was the only deciding factor when I chose Postgres over MySqL earlier this year for my company.
If you want to market to linux nerds, you need to change the perception of the company, because that's what matters most right now. Stop being evil, and then we'll give your products a chance.
In all honesty I can understand where you're coming from. However, there is a discrepancy as far as I'm concerned between what you're selling and how you're selling it. In this case you are trying to sell quicker updates, better stability and performance to mostly enterprise customers, with a "we all like to geek around on linux" attitude. If you were trying to sell me on using Oracle Linux for my own development PC the tone would have been quite fine, but for your target audience it seems slightly out of place.
Furthermore, if you are indeed correct and Oracle Linux is something useful that a lot of people will benefit from I seriously doubt that zealotry will stand in the way of its adoption. I guess we will have to wait and see.
Honestly, my target audience with this page is precisely Linux enthusiasts.
Presumably the enterprise customers are all either running RHEL or are already buying Oracle Linux support contracts, and wouldn't be interested in "Oh, I could just run this CentOS-like thing for free".
So, my question is: What's the story on ZFS and DTrace?
I realize I could answer my own question with a little searching, but the main reason I would consider an Oracle branded Linux distribution would be for a reasonably 'official' way of getting some of what made Open Solaris compelling. Whatever the story is, I think my curiosity is predictable and common enough to warrant a mention in your article.
I should note that I am completely uninformed, and only have a passing interest in these things. What little I know is second-hand and years out of date. Although I just did just do a 'sudo yum search zfs' on RHEL 6, which is the only search I should need.
My understanding is:
There's a DTrace beta for Linux. There are no plans to port ZFS to Linux (but, Oracle is investing a lot in making btrfs kick ass).
I'm not looking for a 'kick ass' file system... ZFS does have some features I am interested in though, and I would appreciate having it made available to me somehow.
I was going to leave you alone about the 'messaging' aspects of your post, but now I'll point out that your reply exhibits a similar tone.
Or pragmatism borne out of watching Oracle be a slimy, evil steaming pile of douchebaggery that has only been recently surpassed by Apple in the corporate warmongering department. It's like CentOS, with a heaping helping of evil in every bite.
Now for recommendations there are a lot of directions that you can go:
* for one the language has a lot of features that all the fancy frameworks use, you should know these so you don't end up using some blown up solution when all you needed was a simple servlet. This would include things like: collections, generics, annotations, enums, concurrency, IO & NIO, JAXP, sockets, servlets, JSP.
This part is pretty heavily covered in Bruce Eckel's "Thinking in Java". Not the easiest read, but definitely a very complete language reference. Servlets & JSP are pretty well covered in "Head First Servlets & JSP".
* another point to consider are general practices that transcend language such as coding practices, design patterns and testing.
You already mentioned "Effective Java", which would be the first one I would recommend in this category.
A very good book about coding practices based in the Java world would be "Clean Code" by Robert Martin. "Head First Design patterns" are very easy to digest, while the "Design pattern" book by the GoF is heavier reading. For testing I would definitely recommend you have a look at "Growing object oriented software guided by tests".
* depending on your field of work you might or might not be interested in Java memory stuff. This includes things like how and where objects are kept in memory, gc algorithms etc.
Have a look at this presentation from JVM tuning at Twitter and see if this is your thing: http://www.infoq.com/presentations/JVM-Performance-Tuning-tw...
* finally, and in my opinion the lowest return of investment you could get, is by going for some framework. Not that this is bad, but generally frameworks tend to have shorter lifespans than the language itself and they usually change between projects so all your new Spring chops might not help you on your following project that uses EJB.
I'm not going to recommend anything here, since this is a very fuzzy topic and it depends on the problems you are tackling.
Let me know if you need other ideas.