Nearly 20 years in now as a self-taught developer.. and I agree with most of what the post says. I would just add that a young person should continually keep trying to get a job, any job, building software. The process of applying for these kinds of jobs helps you identify areas to focus on.
I think the biggest thing that keeps people from being successful is the assumption that, even with all the effort they are putting in, their potential peers are better at the job. In some strict sense that is true but delivering customer value is number one. Keep your focus on that, people will want to work with you. Ignore any feelings of being an imposter.
I got my first contract development gig at 14, first salaried position at 17. Stick with it and make it happen. Be confident. Don't be a dick.
Also, the original question talked about using Java. There is nothing wrong with Java and there are a lot of jobs in that space but I can't imagine a harder place to come in as a young untrained programmer than Java Enterprise development.
> but I can't imagine a harder place to come in as a young untrained programmer than Java Enterprise development.
It's funny, I can't think of a better place. Well-established companies will have the money to support you as you learn, cogs move slowly in these orgs so you don't have to rush - take your time as you learn about the code base, and figure out how things are done certain ways and make suggestions to improve.
Ya I understand that, if you can get in the door. Those same companies are also the ones I've found more likely to automate rejections of applicants who can't check the right boxes though, making it harder to get in without experience.
This is true, I guess networking is key here - I got into that kind of company by reporting a bug on their website and explaining it over coffee with one of the tech leads. Hired the following week.
The enterprise isn't the only place you'll find Java.
As much as the title pains me to type here (as a former C/C++/Assembly snob), I've been essentially a "Java programmer" for the past 5-6 years due to a focus on native Android development.
There is a pretty important distinction here -- We have seen in the US consulting market (at large corporations) an influx of 90s style contractor arrangements for staff augmentation. This is basically the counter to failed outsourcing efforts. These contractors almost entirely work for large groups like Robert Half, Tata, Infosys, Tek Systems and others.
We also still have a very very strong consultant labor force making 2-3x what W2 full-time employees can pull in. These consultants generally work through smaller consulting firms that take smaller cuts for the placement/handling billing and invoicing.
Perm - Mid level benefits + Pay (maybe options in a startup)
Contractor - Individual with their own Ltd company, pays less tax and much higher take home pay but without any benefits.
Consultant - On-site via a supplier on a framework of some kind, however, often a permanent employee of the supplier with the supplier cashing in the margin.
At least 50% of the tech workforce in companies I work with or where peers are at in London are made up of contractors, especially in Banking.
Using an admittedly expensive Asus RT-AC88U with my MBP connected over 5ghz, I can get ~900mbps on speedtest.net using my gigabit connection.
Example test below [0], admittedly the downstream results aren't the best but I've got some rather large downloads and streaming going on right now. Upstream shows the capability though.
That is pretty damn insane for real life speeds. Most reports I've seen say ~400.
I must admit I'd probably not upgrade anyway though. 100mbps is enough to carry a couple 4K video streams in parallel. So not going to outgrow that speed anytime soon.
LAN also outperforms wireless of far higher speeds for certain work, in my experience. 10mbps LAN readily trounced 200mbps wireless for SMB file sharing, for me.
I attribute it to less dropped packets, less interference, and full duplex, despite lower bandwidth.
Good wifi deployment shouldn't lose packets ever. 802.11g (54MBit) easily reaches 20Mbit so your deployment had to be utterly terrible for 10Mbit Ethernet to outperform it.
Don't forget that Wifi needs to be properly positioned to work quickly.
> Good wifi deployment shouldn't lose packets ever.
You lose packets to radio interference (or collisions). And SMB in particular reacts poorly to packet loss.
You're also assuming that "good" wifi deployment is a reasonable expectation. People just buy that blue Linksys thing and put it near the jack for the modem. If you're going to run wire all over the place for access points then you might as well run wire all over the place for ethernet.
>Don't forget that Wifi needs to be properly positioned to work quickly.
And if my properly positioned you mean "In a faraday cage with only the AP and your station", you'd be correct. The issue is real world WiFi doesn't ever work that way. There are very few places where you don't pick up at least one or two neighbors using at least some of the channel bandwidth you need. Even inside your own wireless ___domain you have the hidden node problem, forcing wireless domains to be broken into small cells using low power greatly increasing the costs of deployment. Add that a huge number of cheap APs and computer drivers flat out suck and the average non-professionally installed wireless user is not going to see 50% of the bandwidth they should.
Thing is, you really need the "300Mbit" rated 802.11n to get reallife 100Mbit in good conditions. In a lot of cases only 802.11ac capable devices really go over 100Mbit - the 1600Mbit stuff is mostly just marketing speed unreachable in practice.
When teams have problems with remote v local employees, I've found this to be because they actively treat them differently, sometimes without realizing it.
It takes work to establish your culture to work remotely well -- if you just hire some people that you only ever hear on Skype during standup and give them work, they don't become enmeshed in the fabric of the company. Cliques form everywhere but they can be especially brutal in excluding remote workers from the 'core' teams that are seen as successful within a company.
I'm sorry to hear it hasn't worked for you. If you attempt it again, make sure you evaluate whether you've built a culture based on 'being there' before hiring people who can't be. Lots of people make this mistake and just see cheaper workers.
When teams have problems with remote v local employees, I've found this to be because they actively treat them differently, sometimes without realizing it.
Yeah, some teams like to take advantage of the far richer communication that's available in person rather than handicapping everyone to the lowest common denominator.
If you attempt it again, make sure you evaluate whether you've built a culture based on 'being there' before hiring people who can't be.
IOW, discourage informal social interactions between employees. Don't permit them to go to lunch together and talk at leisure about things.
Companies do not like spending money they don't have to. So since the Internet hasn't killed business travel, there must be a very good reason its still worth it.
I think your last point about data retention is really the big question. Given the ever-growing use of Parallel Construction in making cases from illegally obtained data (or data authorized only for a different use), its not enough that all these policies be stopped -- we need to address how long they can keep the fruits of their labor.
We're building on/and hoping to contribute to the community Code Fixes/Code Actions being built for Roslyn as far as refactoring goes in C#. We have some plans of providing a similar interface for other CodeEngines to implement diagnostics/fixes.
The font is Input Sans [0]. Great font. We wanted to try and package it with Scrawl but we never heard back from the author. Its free though, go try it out!
We've got more direct support for Angular, Knockout and React in the backlog but I don't want to lie to you and say its happening tomorrow. Soon though. Thanks for your feedback!
Founder of fluentCODE here. Really happy to see this posted, we just pushed really hard last night to get the site up. Lots of good comments -- I'll just add that we will be a lot more than just a C#/VB/JS editor. We've got plans to build CodeEngines for F#, TypeScript, CoffeeScript, CSS/SCSS/SASS/LESS, PHP, python and lots of framework specific bits for each of those.
We're a small team working hard on a product we believe in. Ask anything and I'll try and respond if I don't fall asleep!
FYI, Go is missing a full featured IDE and Go is picking up steam. Not much competition in this space yet although JetBrains I think started putting real effort into the plugin.
I really like Go and have definitely felt there's room for great integrated tooling there.
I want to do Go as one of our early code engines. We'll probably start off using srclib for early Go support and then build up some bigger features around the compiler tools, go fix, and so forth.
We want to do some cool stuff with SQL down the road. We'd start with features like a query result browser, but could expand that into things like query analysis too.
We don't have it pegged for a specific release just yet though.
Yep! It's in the backlog; to start we'll probably use srclib [1] under the hood to provide the code intel bits, and we'll do some special UI wrappers for bundler/gems.
We've been working hard to make srclib's backend more powerful, and we've just started to build features that take advantage of the new backend. I've sent you an email, and we'd love to work more closely as srclib nears v1.0.
I think the biggest thing that keeps people from being successful is the assumption that, even with all the effort they are putting in, their potential peers are better at the job. In some strict sense that is true but delivering customer value is number one. Keep your focus on that, people will want to work with you. Ignore any feelings of being an imposter.
I got my first contract development gig at 14, first salaried position at 17. Stick with it and make it happen. Be confident. Don't be a dick.
Also, the original question talked about using Java. There is nothing wrong with Java and there are a lot of jobs in that space but I can't imagine a harder place to come in as a young untrained programmer than Java Enterprise development.