ventureaaron wrote:
If you have a big enough hammer, everything IS a nail.
My new response in design meetings, from now on! Where would you like your case of beer shipped?
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
Just noticed your sig, CodeWraith ("evil lasagna")--I love that movie!
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
I've done both--worked as an in-office coder for a big govt contract, jumped into freelance/contractor work, and now I'm back in the office (though working remotely 800 miles away--so that's a plus!). As others have said, there really aren't any single guides to being ronin developer. Getting onto a team is a good way to start (how I did it), so you have other people hustling for job and will call you as their go-to guy. That's networking in its best(?) form, in that the work you do proves your worth. Putting the word out that you are interested in contract work is also really good--people will call you constantly, and you can pick or choose, depending on what they want and availability. Money, though, is the biggest factor. In my experience, it's pretty much feast or famine. When I was working with a team on a big contract, I was making crazy-good money (esp. for my area). But when the work dried up (more on this below), I spent about 16 months trying to limp along, until an old contract customer called me up and asked if I'd like to come back as an employee...which is where the brave hero of our story finds himself now. My mistake was to let the guy who was organizing these contracts become my sole source of jobs. I spent way too long (about 16 months) tagging along while waiting for him to find the next whale, rather than going out looking for other work on my own. Add into the mix some tax shenanigans (on his part)* which left me with a hefty tax debt, and I decided to cut loose from him. I was able to find a couple of good-enough paying jobs here and there, but I was happy to take the offer from my former customer when it came along. Personally, here is how I would recommend getting into it: First, try side jobs--taking small work that you think you can do in your off time. It'll get you into the feel of dealing with contract work, as well as dealing with the different pay methods and tax issues that come along with it. At the same time, you'll still have your regular job to keep the money coming in. This period will allow you and your family to adjust to the idea of odd working hours and having a home office (if you don't already). At the same time, you'll also need to set up whatever business/accounting structure you need in your country to handle the payments. I don't know what it's like where you are, but in the US, DO NOT SKIMP OR PUT OFF TAX PAYMENTS!! If you get a payment of $100 for something, just bite the bullet and make the payment of XX% of that. It's easy to skip
I'm with Griff, on this one. 1. For formal letters to an individuals, it was "Mr." or "Ms." and last name. No knowledge of marital status necessary--"Miss" was already out the door (typing class from 30+ years ago) 2. For mixed groups (male, female) audience, use "Ladies and Gentlemen," (military knocked this one in my head) 3. If you're _sure_ it's going to be a male- or femal-only audience, "Gentlemen," or "Ladies,", respectively. (again, military). All of these are, at their base, built on older views on how societies work. OTOH, they generally get me through all the more common sticky wickets.
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
Budget and time. The primary contractor (a Dept. of Energy nuclear cleanup project) had taken over the system that was already in place as part of the original requirement. The site had also been running for about 50 years prior, so they couldn't just dump the historical data. Spending big $$$ to do a migration (with all the sign offs from all parties involved) was going to bust the budget, as well as take too long. Instead, they had the idea that we could just build an overlay on the existing system that would automate the work previously done by all the managers and foremen. It wasn't really a horrible idea, except that all the people who knew what needed to happen (the rules, restrictions, and such) had either left the site at the change over or were not involved in fleshing out the requirements. So it was a like a fractal rabbit hole--go down one, and you only see hundreds more inside.
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
I spent about 6 months in developer hell working with JavaScript ("cool--now can you add these 5 things?") about 5 years ago, and was fairly deep into some of these concepts. Basic premise: Create a web UI to do scheduling for 5,000 workers (construction, lab, etc) that talked to the (very old) scheduling system. Kink in the process: Needed to account for all sorts of static scheduling rules (start times, end times, allowed ranges, etc) and a variable list of union rules (lots of different unions on site) to match up and validate the work, the pay rates for job type, and such. My JS coding was definitely old-school style, but prototypes were what saved the day. Date and time handling, rules, etc allowed me to push the common functions further up the chain, and going between 5 different datetime formats certainly made a difference. Same for the "rules" concept--basic rules and functions, and subclasses for specialized parameters. The whole thing was cancelled just as it was getting functional ("Oh, wait! We need to get 5 departments and 3 unions to sign off on this"), but I definitely learned a lot.
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
I use a variant of the marble track ball. Like the other guy said, it's my go-to and I've been buying replacements for years.
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
I second @Lopatir's experience--mine has been almost exactly the same. If you are going into the world as a individual contractor, you're going to be working the business side of things, too. You can get "brilliant coder" positions, but almost never directly. In my experience, it's feast or famine with contracting. There were a couple of years where I worked my butt off and made crazy money...followed by a year and a half where I was getting well below minimum wage, when averaged out. In that case, my problem was that I let myself become too dependent on my "guy" who was getting me work. His contacts dried up, and I didn't have many of my own. The last bit of advice is where I am now. After some time, one of the sites where I did some particularly complex work asked me to come back. It's about low-middle industry average, but the pay is steady and my wife appreciates the predictable hours. I haven't given up on going alone again. Once you've worked as a masterless ronin, it can be addicting (flexible hours, freedom to give your best technical opinion on things, etc). But you also learn to appreciate some stability and not get all worked up about job security. After all, you've made it on your own before...
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
I haven't seen anyone else mention it yet, but I use the paid version of Mikogo for business meetings with clients (when I'm working as a contractor). It works really nicely and I haven't hit the limit on participants yet. It includes VOIP that works really well, but the meeting is all-VOIP or all-phone (dialin), so the lowest common denominator wins if you have a mixed bag of attendees.
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
I vote genius! It's an ad site, intended to get people's attention and stick out in their memory. Someone put a lot of work into the humor. This gem is in the JS code, too:
Ling aims to do everything right, first time. She punishes herself and staff for making mistakes, so they happen very rarely.|;|Ling always complies with the Human Rights Act (Chinese rules), but it's usually her staff who get shot, not her customers.
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
A lot of really good advice here, and it reflects a lot of the techniques that I use to learn and get things done: Take on projects that stretch your capabilities, try to explain the issue to someone else, talking it over with another coder, etc. One that I haven't seen mentioned is this: Really really put in the time to learn some deep basic knowledge, such as data structures, algorithms, and computation theory. I spent about 8 years doing coding work, both on the side and for pay, and I was pretty good at getting things done. I learned like you did, and felt pretty adept at taking on new challenges and expanding my repertoire. Then the business I was in went under, and I used my GI bill to go back to school (rather than call myself unemployed) for a graduate degree in Comp Sci. Out of all the classes, it was the Algorithms, Data Structures, and Computational Theory classes that taught me the most--and it all came together in the class where we wrote a basic operating system from scratch. (I had never had these classes before--I was an Aerospace Engineer from way back, and took up software development because, like you, I enjoyed it and had a lot more patience for coding than anything else) When I went back to work (needed the money more than the degree), I found that my problem-solving skills (and even better, my "problem-recognition" skills) had improved tremendously. And because I had a better understanding of how computers work, the particular language I was working in became less important than figuring out what the software needed to do as a whole. You don't have to actually take classes, but it's like automobile maintenance: If you don't understand the basics of electrical circuits and 4-stroke engines, you can still get the job done, but it'll take a lot longer and there's a lot of "magic" involved. Learning the underlying principles of hash tables, stacks, sorting algorithms, and memory management makes a world of difference. ...and BTW, even with all this, I still run into problems that take me 2-3 days to figure out, even if the final answer is simple. But it's the ability to find this "simple" solution that we get paid for, right?
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
I used to just run through every song I had with shuffle on, but then (unintentionally) start to put certain albums or songs on repeat. I think that I've been seeing the same effects (good and bad), but wasn't really analyzing it until now. Do you put together playlists and then pick them for a project/language type, or do you edit the playlists as you go along? I'm curious, because it seems like there might be something worth digging into a little. Maybe even a programmer-focused playlist addon to VLC or something?
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
This has probably been discussed before, but why not go around again? (...and, of course, I'm too lazy to dig through the archives...) So my wife got me the new RWBY disk, and I was looking forward to the fun of working on a side project in Ruby (the language) while binge watching all the seasons. I had just finished up the Trigun series doing this project, so it was time to change up the entertainment. Thinking about it, though, it seems that a kind of system has emerged. When I'm working on C projects, I usually put in a series of horror movies: Mama, Mirror, Altitude, the new/old Evil Dead movies, etc. Must be something about demons and pointers that just go well together. Ruby, my newest coding language, seems to have me pulling from the anime shelf in my collection. When I'm in the home office for my day job, I have VLC running through some playlists or albums on my headset so I can concentrate. But even there, I seem to have some go-to music, depending on what kind of project I'm working on. If it's a C# project, I tend to play Five Finger Death Punch or Disturbed a lot (that might be self-explanatory). If it's a Java project, I tend to have Green Day or Meatloaf. OTOH, if it's working on the database design, I tend to play a lot more 80s stuff. So my question is this: Has anyone else noticed that their taste in music or background noise seems to change according to what kind of work you are doing? Or is it truly just white noise to help you concentrate?
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
Joe, is that you? I didn't know the Change Control Board ever let people out of their dungeon! Or did you dig your way out with a coffee cup and a USB key, again?
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
We have 29 doors in our house, and we just started going through and changing all the interior doors from commercial (paper, plywood) to oak doors that we get raw or build ourselves, then stain and finish. It still takes us 20-45 minutes to finally hang a door, even after hours of measurements and sanding (and that doesn't count the hours we put into the door frames!) I would never be able to make a living out of this.
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
If you have any sysadmin experience, I would recommend using a low-end web server hosted on AWS. Like others have mentioned, you can use GoDaddy or something else for your DNS (I use DynDns, myself). Depending on the size of the server, the cost itself is slightly higher, but having full control of your machine has always been my preference--GoDaddy and others are usually a PITA if you want to do anything outside what they consider to be "typical" web hosting. Cloud DIY is not for everyone, but having a machine all to your own is the best bet. Before that, I preferred to run them out of my home office. (Also an excuse to keep fiddling with "teh servers" for no reason...)
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
This, imho, is exactly the point for today's environment. Maybe not so much in the future... "Programming" is...well, not easy, exactly, but fairly simple compared to the real world. At the highest level where users see "Hello, World!", a computer is a computer is a computer. Compilers take care of the rest, and hide all those ugly choices like "add r0,r0,r1" vs "add r0,r1" at the assembler level. Once you start dealing with the outside (of a computer), things get very complicated. The software for a Roomba won't work on a Cyberdyne T-101, and vice versa. Even if the computers were compatible, the task "get rid of that crud" has to be carried out completely differently, mechanically, on each system, which means that low-level commands would have to be different, thus the math, ad nauseum. :-D It might be different if robotic platforms (and their manufacturers) settle on the equivalent of "frameworks" for both the computational side and the manipulator/motivator side. Kits and microcontrollers like the Arduino, Lego Robotics, etc. are all a move in the right direction, but your industrial automobile welder is still a world away from a home made robotic arm, even though they might perform the same tasks. Until then, though, it's going to take a lot of low-level work in both software, hardware, and in-between to get even the most basic robotics project up. Some people love this--I'm working on a homemade trirotor drone made out of $5 of sheet metal from Lowe's and pop-rivets--and they will keep it up. For the average developer, no matter how brilliant, it is usually too much of an investment of time and labor that, in the short run, doesn't really pay off much, even if the pay off is just seeing something move.
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
Had problem like that--"legacy" web app written in some third party take on ASP.NET and JSP. It was "legacy" in that the code was written before we took over a contract by another contractor (so no going back to them without major $$), but it was only a year old. Now that we were responsible, the users were asking that we fix the weird issue of extremely poor performance and daily lockups of the entire system. I was given the task of figuring out how the code worked so I could go through and fix it. When I finally get the source code installed and 3rd party IDE up..."Hmmm...almost zero logic in the code as far as I can tell...these are strange calls..." I go look in the database, and voila! All stored procedures. I tell myself, "Okay, I can work with this!", and start scrolling through a stored procedure... ...and scrolling... ...and scrolling... ...and scrolling... Oh My Elephanting God! One stored procedure (the one that was suspected in causing the lockup) was 12,000 lines! And there were 30 more! Tried printing it out to do a manual refactoring--it was 250 pages of stored procedure SQL, and there was no consistency in anything. My final report back was this: 1. This is a horrible app. 2. If you want it "fixed", I need 6 weeks and the option to just rewrite the whole thing in a more stable and common language (.NET, JSP, assembler, whatever...I didn't care--anything would be better than this nightmarish blend of old ASP and Black Speech). 3. If you want it to run "better", move it to a big iron database (we had several) and don't look at it until you want to rewrite it. They went with option #3. Every 6-8 months, I would be told to take another look, and occasionally I would be able to make a small modification that wouldn't crash the whole system. I left a few years later, and as far as I know, it's still out there, a monument to both Horrible Implementation and "The problem I couldn't crack".
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
I've been using AWS for both Tomcat/Linux and IIS/.Net web applications (haven't used the others). Overall, the price is good (good enough that I haven't shopped around), and the access for the MS instances are pretty much standard to any remote access and configuration. For me, the biggest learning curve was AWS terminology, understanding the startup and configuration, and setting the firewall/access rules. This was several years ago, and the tools for these things have become much better. (I even used their AWS-SDK for Visual Studio to create some mass-AWS management for a client last winter. It was actually pretty easy.) I would recommend at least trying the free tier for AWS. You get a no-cost tiny virtual machine that you can configure and install IIS and SQL Server, run your app, and see if you like it. As long as you don't have (relatively) heavy data IO, you should be able to test the whole thing and see if you like the service. If you have any questions, I can try to walk you through the first few steps (the ones that are part of the learning curve)--after that, you should be able to take it on your own.
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"
AND A VERY IMPORTANT LESSON
vuolsi così colà dove si puote ciò che si vuole, e più non dimandare --The answer to Minos and any question of "Why are we doing it this way?"