Me/CV/corp: Difference between revisions
(→Footnotes: further reading) |
|||
Line 61: | Line 61: | ||
* [https://danluu.com/hiring-lemons/ Developer hiring and the market for lemons] "...almost [every employer] uses the same filters [for screening applicants], so everyone ends up fighting over the 30 people who they think are solid. When people do randomized trials on what actually causes resumes to get filtered out, it often turns out that traits that are tangentially related or unrelated to job performance make huge differences." | * [https://danluu.com/hiring-lemons/ Developer hiring and the market for lemons] "...almost [every employer] uses the same filters [for screening applicants], so everyone ends up fighting over the 30 people who they think are solid. When people do randomized trials on what actually causes resumes to get filtered out, it often turns out that traits that are tangentially related or unrelated to job performance make huge differences." | ||
* [https://danluu.com/wat/ Normalization of deviance in software: how broken practices become standard] | * [https://danluu.com/wat/ Normalization of deviance in software: how broken practices become standard] | ||
* '''2014-06''' [http://carlos.bueno.org/2014/06/mirrortocracy.html Inside the Mirrortocracy] | |||
==Footnotes== | ==Footnotes== | ||
<references /> | <references /> |
Revision as of 21:08, 12 June 2017
Executive Summary
I loathe self-promotion, so I'm not going to try to shoehorn my history into something conventional-looking. If that's what you're looking for, you can toss this one out without reading any further. Have a nice day.
If you're looking for someone with academic degrees or other formal qualifications, I won't waste any more of your time: I don't have any. I was dealing with intense depression for the year and a half I went to college, failed miserably, and soon found that I enjoyed being paid to code rather more than paying to be told I'm inadequate.
Immediate Requirements:
- Workplace must be a safe space with a culture that is supportive of diversity and the practicalities of getting work done.
- I enjoy making people's lives better by solving problems. I also like being paid a living wage or better. I am willing to work for the greater benefit of the plutonomy (i.e. against the public good), but it will cost extra. My fee for enriching your investors through my work starts at $120/hour and goes upward for larger companies; endeavors of a less parasitical nature may negotiate downward from there. (I will obviously want to know more about how your company or work is beneficial, how any profit is shared, etc.)
- I prefer to work remotely, but am open to other arrangements if there is a good reason for doing things differently.
- I am not open to relocation on a permanent basis, though I might consider temporary relocation for a span of time. (This does, however, raise the price.)
- I do not make phone calls. I do not answer phone calls. Business communication belongs in text and non-ephemeral media.
Long-Term Requirements — These are not deal-breakers, but if they are a problem I will agitate whenever I bump into them:
- I am allergic to BS, especially the authoritarian varieties.
- No cube-farms, no compulsory meetings for no apparent reason, no power-games or headgames.
- Must use good collaborative software (project management, wiki, chat, etc.) and have good channels of communication.
- No deep/sacred hierarchies. No "performance"-worship. There must be respect for the long-term sustainability of the enterprise.
- Needs and requirements for any given project, or the impetus for evaluating needs and requirements, must be stated clearly and must not arbitrarily change.
How I can help:
- I design software/business systems and subsystems, either solo or as part of a team.
- I can produce documentation to any required level of detail, and beyond.
- I'm deeply into PHP[1] and fluent in SQL (especially MySQL)[2], with at least 5-10 k hours of coding time (best guess).
- I am intimately familiar with Linux system administration, especially the LAMP stack, though I'm still struggling with proper configuration of SMTP servers such as Postfix.
- I typically learn new technologies by using them, so am willing to attempt whatever other tools you might need me to become familiar with; in return, I will let you know if I see any better options.
History
Note: In blatant violation of hallowed CV tradition, the following is in forward-chronological order because it makes more sense that way.
In 1972 I wrote FOCAL-69 code on a PDP-8/L, but I misunderstood the line-numbering system and none of my programs worked right. (The lapse seems understandable given that I was only 8.) I did successfully learn how to manually enter the bootstrap code using the front-panel switches, however, and was able to load programs from punched-tape without assistance.
In 1975, 5th grade, I wrote artistic graphics software in BASIC on a Tektronix 4051. I still have many of the plot-outs.
In the early 1980s I did computer hardware setups / testing / evaluation / shipping in my mom's computer store.
From 1985 to 1989 -- my first real, non-family job -- I worked as a coder and lab assistant for Dr. Russel M. Church in the Brown University Department of Psychology. I started out writing in DEC FORTRAN IV on a dot-matrix teletype, soon graduated to a video terminal, was upgraded to FORTRAN 77, and eventually persuaded Dr. Church to bring in a PC and Turbo Pascal. I wrote software for data analysis (spreadsheets were not yet widely known) and running experiments. It wasn't super-exciting, but it was dependable and engaging.
From 1990 to 1991, I worked for the late great Dr. Frank Borchardt at Duke University's Humanities Computing Facility doing language-related neural network (NN) simulations. Having found existing NN software packages opaque, buggy, inflexible, and difficult to use, I wrote my own NN trainer in Borland Pascal and ASM86. Although the simulator worked well by mid-1991, developing it at that stage was probably a mistake; I should have been focusing on more prosaic efforts to produce positive results. I severely overestimated the level of "research" that was wanted / expected. In retrospect, although I learned a lot of interesting stuff about neural networks, I probably should have stayed in Providence and not taken this job. (Also: Frank was a great guy, but notoriously difficult to work for.)
From 1991 to 1997, I was living in poverty in Athens, GA, having arrived right at the beginning of a recession and consequent hiring freeze at UGA (source of most computer-related work in the area). I did eventually get work there, at $5/hour, doing image processing in Visual C and data manipulation in Borland Pascal. (Object Pascal was, at the time, as much of a strength for me as PHP is now, with C++ a close second.) I also spent a lot of time pursuing independent software projects (including further development on the neural network program), but was unable to make much headway due to the chaotic work environment. Being a glutton for punishment, I was also trying to start a business... actually, I tried to start one business (recording studio), and was persuaded to start another one (online store for independent musicians) which then morphed into another one (online store selling mostly mass-produced t-shirts), but that's another story.
From 1997 to 1999, I worked for Pierce Manufacturing in Appleton, WI. They had issues, and I learned a great deal about how not to run a software project.
- The red flags started on my first day: there was no PC for me to work at, and nobody knew when one would be available. Given this, I went house-hunting for a couple of hours, off the clock -- only to hear (when I got back) that higher-ups were annoyed because I hadn't been there the whole time (doing nothing in an approved manner, I suppose).
- Additional red flags, had I known enough to recognize them, included: adding developers to a team when a project was running behind, demanding more frequent progress reports and meetings when a project was running behind, moving the team around to different locations when a project was running behind, and a supervisor's consistent failure to facilitate communication between the software team and the older hands in the company whose business processes we needed to understand. (I did actually recognize this last problem, and went over the supervisor's head with an email -- which did finally effect some change, but that's when things started really feeling off-kilter.)
- There was never any respect for my attempts to find a better, less-distracting work environment by working from my rental house, on my own PC; management seemed to see this as somehow evading work rather than trying to do it better.
- We finally ended up in a small, windowless room, without even any partitions between workstations, working weekends (we had been averaging 50-60 hours per week by that time, with overtime being paid at 150%). Each of us was taken aside one day and brought to a higher-higher-up's office (Dave someone... lots of Daves at that company...) for a few minutes of discussion, after which I was immediately let go and escorted out of the building. Fun times. Due to all the overtime, I did quite well financially that year – but Pierce would have done much better to keep the development team on a 40-hour week and instead offer some basic services, like meal delivery and laundry, rather than paying through the nose to try and squeeze a few more cycles out (which generally doesn't work).
From 1999 through early 2001, I worked for Carrier Transicold in Athens, GA doing Visual Basic database work (MS Access, MSSQL) documenting and designing business process software. Fortunately, their IT department had a much better understanding of software development than Pierce did, and we got a lot of good work done.
- One early project was y2k remediation; this project was completed over several months, quietly and on schedule, by basically two people (Ed and myself), with some help from the PHP-11 support people in Syracuse. There were no unfortunate date-related incidents in any of the software within our purview.
- Another project which emerged from the y2k remediation involved bridging Windows-based database software (upon which front-office operations were increasingly dependent) with the older DEC PDP-11 business system running "ManMan"; this too was completed in short order. It was still in use during my second (brief) stint at Carrier a couple of years later.
- My work there only came to an end when upper management abruptly issued a directive to terminate all contractors, throughout the company, without warning. My supervisor (Ed) was not happy with this.
From approximately 2002 through 2008, I was reworking VbzCart and writing the beginnings of the application framework which later became Ferreteria while also suing my former business associates. I also did a short stint consulting for Carrier, handling the help desk on site for a week so Ed could take a long-needed vacation and then doing a little VB work remotely (from Durham). For the second time, upper management put the kibosh on this work by terminating all contractors without notice.
From approximately 2009 through 2013, coding work ground to a near-halt as multiple family crises diverted all of my focus-time. I finally had to mothball the store in 2011 when part of the checkout process broke. From 2010 to the present I have been doing occasional office-network and web site support for Sage & Swift, a Durham catering company. From 2011 through 2014, I managed to squeeze in some semi-regular web site back-end (PHP/MySQL) work for Swashbuckler Interactive, a small web design/development company then located in Durham (now moved to Colorado).
Starting in late November 2016, I adopted a new regimen of working for several hours very early in the morning (waking up generally between 3 and 5); this has at last allowed some visible progress on various coding projects, primarily Ferreteria, VbzCart, and Greenmine.
Further Reading
- Developer hiring and the market for lemons "...almost [every employer] uses the same filters [for screening applicants], so everyone ends up fighting over the 30 people who they think are solid. When people do randomized trials on what actually causes resumes to get filtered out, it often turns out that traits that are tangentially related or unrelated to job performance make huge differences."
- Normalization of deviance in software: how broken practices become standard
- 2014-06 Inside the Mirrortocracy
Footnotes
- ↑ PHP is frequently mocked for being too easy to use; I'm perverse, and consider ease-of-use to be a requirement.
- ↑ Don't ask me to produce flawless code on a whiteboard or piece of paper. Whiteboard coding tests are silly and ineffective. I took one once, thinking it was just a basic test of familiarity with code – but apparently it actually mattered that I made a syntax error.