I think that's the key difference to an experienced dev/BA. One who can actually sit with the stakeholders and build the system on paper and go through each of the problems as the diagrams connect. What you end up with is the stated requirements (tip) and the unstated assumptions (iceberg).
These types of projects are easily spotted as they're often called "quick" or "easy", which in layman's means no one's really thought about it yet.
Reminds me of an old saying: "If you don't know how to do it, you don't know how to do it on a computer."
Once you learn and understand the learning algorithms, you will experience this Wizard of Oz moment, you see how the trick's done and it's not quite as impressive as you hoped. This is confirmed by the fact that it exactly matches the limitations of a typical neural net you've established experimentally.
The tasks that are within these limitations, they perform quite well at, but it's not that hard at all to understand how they are performed. In most cases you can basically run the algorithmic equivalent of a trace debugger on the system. In as far as you can compare it with a brain (but don't do that, it's the wrong analogy--compare it with statistical regression instead), it's one you can take apart entirely, reassemble, run partial components of, tweak, and understand exactly how it works to the instruction level. Plus you can do these things automatically for the most common cases.
In short, there is nothing "magic" about neural networks, or any pattern recognition algorithms.
And to get back on the subject, if you intend to work with machine learning algorithms in a professional/consulting/project setting, probably best to first check the scientific literature to see if anything like this has been done, and what the accuracy/false positives/negatives/ROC curve is that you can expect. Don't expect to beat them, either (you may, but planning to do so by any significant amount is asking for trouble--especially if it turns out it just can't be done). Then, I think it would be clever to first build a "fake" system/interface, without the ML component, limited to just the labeled training examples (if you can't acquire these, give up now), see if the system is actually useful from a software engineering, application and usability perspective, before you actually begin (the fun part) tweaking an ML algorithm, only to later turn out, even if it did its job perfectly, it wouldn't be all that useful in the operating environment in the first place.
This is different if you work for a corporation with a huge research budget, of course. Like Microsoft or Google. But even then, I think that for their ML-enabled end products, similar reasoning like I sketched above is used. Of course the same goes for every type of project that depends on an unknown to-be-researched technology.
 yeah yeah unsupervised learning. but if you know what you're doing that well, why are you listening to my advice? :)
(Emphasis mine.) But that's the point; it may be "auto", but if you understand how NNs work it's not magic. It's not even all that hard to understand (considered broadly), and once you understand how they work it is, for instance, easy to construct cases they fall flat on....
"So it has in effect determined how to solve a problem without your input."
... and it's less "auto" than you think. It figured out how to solve a problem based on your input of sample cases. And there's a certain amount of art involved in selecting and herding your sample cases, so regrettably you can't discard this part, either. Just flinging everything you've got at the NN is not going to produce good results.
If you don't understand NNs, you are unlikely to get good results by just flinging data at them; if you do get good results, it's probably because you have a problem that could have equally well been solved by even simpler techniques. They're really not magic.
The classic example is facial recognition. Training a neural network for facial recognition will result in lots of neurons contributing a very small part of the whole, and only when all (or most) are involved is the answer correct.
To most people, this (emergent behavior) is "magic".
And even then, if it was emergence, doesn't automatically imply we don't understand it or that it's "magic". The famous Boids flocking simulation is a classic example of emergence. It's not very mysterious. Yes large-scale behaviour emerges from simple rules, this is amazing that it happens, but it doesn't hold up a barrier for us to understand, analyze and model this large-scale behaviour. Crystallisation is emergence, again we model it with a bunch of very hard combinatorial math.
But in this case, neural networks are not an example of emergence. They are really built in a fairly straight-forward manner from components that we understand, and the whole performs as the sum of the components, like gears in a big machine.
I think that's what chii was trying to point out; not to say that devising them and training them is incomprehensible.
With your experiences, do you have any recommended reading that would help me with the neural network learning curve?
<8 months pass>
Now we're looking at commercial solutions in an attempt to not have to build this thing and deal with this department anymore.
I agree with you 100%, but the number of people astute and experienced enough to quickly and deeply understand the problem to be solved (and the quirks of the customer) are few and far between. In my experience, perhaps 5-10% of any large IT organization fall into this category -- everyone knows who the superstars are and their time is always at a premium. Drives me bonkers.
Completely true is the thing with the superstars. I knew one myself, a genius in warehouse management systems. If I had him on a project, it went smoothly as anything. if I didn't I stayed in development hell for months. But seeing this guys workload, he wasn't off any better.
But in retrospect, the general direction the organisation took at my last employer wasn't that bad. Execution lacked, so.
Also you can wind up meeting and planning yourself right out of a gig sometimes - which is fine if the gig wasn't truly necessary. But can be bad for your business if you spend hundreds of hours doing this for no compensation. This is a real situation that happens - you get a client that wants a big project and after many meeting and calls you determine that a Wordpress install will suit them perfectly. Their network guy does the install and for all the money you saved them your reward is that you don't get the gig!
Learning to recognize and get rid of those bad clients (or convert them into good clients) is a skill that can take a while to learn.
Being a contract resource for a software company, where management tends to think everything related to software/IT is "easy", is a guaranteed shitty project. They'll second guess and micromanage everything you do. And then when they burn through their OPM, they'll screw you.
The real issue is sales...you make the sale because you have to. Then you stick the project on some poor PM/Ba/Dev who will fight with them forever over this stuff.
Maybe I'm just bitter about the situation that I continually get stuck in.
In any organization as a prospective customer, there are three forces at work that matter to a consultant: users, decision makers and finance folks. Ideally, the decision makers appoint a dedicated person (or team) who mediates users and finance guys to create a coherent road map for the system to be built. What tends to happen in practice is a combination of chance, human errors and conflicts in priorities.
To survive, we must understand ourselves as consultants, the terrain and the opposing forces (anything that prevents money getting deposited in the bank).
Consulting is a business => the individual consultant must shoulder quite a lot on himself:
* Advertising himself
* Finding work
* Meeting prospective customers
* Writing proposals
* Closing the deal
* Writing a contract
* Defining the scope of work
* Nailing what is to be done and what is to be avoided
* Constructing components of software
* (In worst cases) baby-sitting customer's devs / ops
* Testing his modules
* Getting money in his account
So, when we talk with customers, there is inherent pressure in closing the deal versus precisely defining everything. Icing on the cake: back of the mind, you might worry about milkman's bills and the birthday gifts to be brought for your kid's friends. Always have a good runway: six months seems optimum. Technically, even three months should suffice, but it is insufficient for the edge case when these three things hold true simultaneously:
* You've to walk away from a customer in the middle of a project, and
* Dry sales pipeline, and
* Unexpected crisis at the personal front: very close friend in need of money for surgery etc.
God be with you.
Now, back to the main track. The key is to first understand the priorities of stakeholders. The contradictions are easier to grasp once we put ourselves in the individual's shoes:
* [Convenience] The users want everything including the kitchen sink,
* [Accountability for the risk] They want it yesterday but won't commit to it on paper since you're in early sales stage,
* [Cost] The finance folks want stability and the most economical price,
* [Availability] The decision maker prefers to spend the least of her time to be spent on this activity, except when it's her pet project.
These roles may be played by different people or the same person.
Again, we don't have to agree, but acknowledge that things are meant to be imperfect. Most people are actually decent and rational. Now, somehow, the consultant must figure out a good path. To begin, he should have a good handle on:
* The industry in which the customer operates, e.g. BFSI, Energy, online marketplaces, food, fashion etc.
* The nature of the market: oligopoly, crowded, emerging et al.
* The level of Govt. regulation: HIPAA? PCI?
* The customer's position: among top tier, mid-size, small firms.
* Customer's customers: helps to track the wind.
* Standard pain areas in the market.
* How customer's competition and partners survive the pain, specifically the differences among the customer's approach and the competitor's ones.
* The financial health of the customer: if possible, try to talk with their existing suppliers in other arenas (e.g. the guy who supplies printer cartridges, the cleaning lady etc.).
Based on that, assuming we've landed a hot lead, say that we want to convert it to money. There will be a lot of conversations over the phone, e-mail, chats, face to face; what is to be left out of those conversations is really context sensitive. The important parts are:
* What problem we're going to solve for all stakeholders?
* How we're going to solve it?
* Communicating our approach and progress on a timely basis.
* Improving Vulcan skills: like money, expression of anger is a great servant but a terrible master.
I leave out the details on the development process, since it depends on the individual.
Here are a few things which worked for me marvellously in certain contexts and doomed in others:
* Setting expectations by explaining the cone of uncertainty in the estimation process. Always be prepared for some customers, who deliberately mislead you that they don't understand the mumbo-jumbo, projecting ignorance as a shield so that they can ruin you on payments. Mostly you should refuse such customers, unless you're in an extreme crisis on multiple fronts.
* Writing use cases for the modules / systems I was supposed to work. Most customers say that they don't want any time spent on "documentation," to which I reply that writing a document is not "typing" but "nailing the thoughts to deliver higher quality work."
* Creating mock ups using sketching tools (even Excel/LibreOffice can be good enough, if one is pressed too much for time) in the absence of UX designers on the team.
* Writing test cases before writing my code. Helps to ease the integration.
* Optimizing lazily: progressively refining the artefact (document / mock up / test / code).
* Knowing the expected value of each task:
(amount of money * satisfaction * improvement in reputation) / (e-mail tennis * stakeholder's understanding of requirements * payment latency * time spent)
Finally, reducing it to just one sentence: be nice, believe in yourself and humanity, be multi-dimensional and please heed Guy Kawasaki's advice about reading voraciously and omnivorously.
Should you be comfortable, I'll be very glad to keep in touch with you. My e-mail is on the GitHub profile.
Once a VP at a customer told me that a diamond is just a piece of coal that shines under pressure.
The quest to become a jewel in the market can be a powerful initial thrust to work as a consultant. Combined with the opportunity to work in a diverse set of technologies and business domains turns to be a pretty compelling force.
Re: compensation, tptacek and patio11 have shared some great thoughts in the past.
I'm curious about any differences in conulsting approach to data science compared to software products: estimation strategies, what works etc.
The formation of this sentence seems odd to me. Why can't we say it's a fun read because it's a classic example etc.?
If everybody was so picky the size of the IT industry would diminish by 90%.
Higher Order Perl, is available for free download. If you read it you will see some amazing insights into programming techniques most people would have never heard of encountered in MegaCorp jobs. You will also grow a great appreciation for Perl in general and understand how it can be an amazing language of choice for a wide variety of problems.
Together with Modern Perl (also free for download ) this book completely changed my view of Perl. It helped me see through the misconceptions built (most of the times unintentionally) around this language and made me even switch from Python to Perl.
If you're interested, spend a few minutes browsing through one of these books. I think you'll like what you see.
They needed a competitor.
You had the job title "senior web engineer" when the web was 4 years old. That's pretty cool.
I've been brainwashed for many years by my brother, who is a Phd civil engineer, that professions that hijack the term engineer are kidding themselves.
I know it sounds cool, and my current title is 'Senior Software Engineer', but it is all a scam.
Which isn't to say we aren't worth it; I'd like to think we are. Just that we often delude ourselves into thinking that our salary differential is linearly correlated with the economic "value" we generate. It isn't.
Or rather: the "value" of an engineer is a lot like the value of an apartment in a high-rent neighborhood: the price holds in the market because, well, you have to have it, and at (almost) any cost in order to do all the other stuff you need to do, like get around the city and be close to your job.
You also have to have access to food and safe drinking water -- even much more than you need a convenient or semi-stylish apartment. The priority for these isn't just a bit higher: it's categorically higher. Yet their base cost (i.e. the cost to obtain them at nominally satisfactory level) is an order of magnitude less than the cost of your rent.
The distinguishing factor between the two classes of goods is, of course, scarcity. That is why your rent is damn high. And that's why an average software developer can earn twice as much as a decent chemical engineer, and an ungodly multiple of what a great public school teacher makes.
 Along with the fact that high-demand apartments -- like high-demand engineers -- are also, arguably, Veblen goods in some markets:
Comparing with my friends who are still doing ChE jobs, If I was still in petrochemical, I most probably be getting paid little less than what I am being paid now, but working much more harder, longer and more stressed.
Ok clearly I am out of touch then. But seriously, how many SE really gets paid 250k+, even at Google?
Quants is in my mind the same as the petrochemical industry tough, rediculous salaries so that one I can believe.
So, yes, I am an Engineer.
You can't even design an embedded electronics device for a 3rd party (for a company you work for, is ok - industrial exemption) or write software for the same without a PE.
But there are a couple of things that make me personally think software engineering is a misnomer.
Firstly, traditional engineering disciplines are generally pretty black and white. It is applied maths and science. If you build a bridge, you can use physics and maths to pretty much prove that it will handle a particular weight/load and so forth. Software development is rarely like that, and even if you are writing software for an engineer and therefore you could argue that you can prove the calculations the system is generating, it is really the problem domain that is engineering but the way the software is put together is not so easy to prove.
Secondly, I think the term actually does us a disservice. Software development requires intuition, craftsmanship, pragmatism, determination, adaptability, artistry. It also often requires understanding human nature, empathy for users, being able to learn and understand endless problem domains, an eye for the aesthetic. All of these things aren't generally required for traditional engineering disciplines.
I would say that the essence of engineering is a devotion to verifying that the design works like you think it works. Software development often lacks this devotion, but when it is there it is entirely proper to call it software engineering.
#have argued, actually
That's why i call it software development, and i m a software developer.
One of my internships was at a company that did avionics software. Avionics is about as different from Web 2.0 startups as you can possibly get and stay in the same industry. There are very rigorous traceability metrics that pretty much dictate exactly what can go in the software. Every line of code has to be traced back to a particular paragraph in the design doc, which has to be traced back to a particular numbered requirement. Oftentimes garbage collection or even heap allocation is banned to avoid unbounded pauses in execution time. So the behavior of the code is fully specified under all conditions, and often formally verified. This was the one place I've ever worked where I'd hear "So we should write it in Ada then?"
I've also worked in the financial industry. Little known fact about the financial industry: it's not one industry but many. The code that you'd use to build a quant trading model is very different from the code you'd use to build a retail banking portal. The former actually tends to look a lot like academic research code (i.e. a software engineer would consider it shitty, but it has impressive math and gets the job done).
I work in consumer web now, but at Google. We actually do care about latency, and CPU load, and memory consumption, and developer productivity. And so it actually ends up being a lot like real engineering, where you perform experiments to measure the performance of the building blocks you're using, carefully consider goals and trade-offs, make estimates and back-of-the-envelope feasibility studies before implementing, and then rigorously test that solution.
This is in complete contrast to when I had my own casual gaming startup, where neither performance nor reliability mattered all that much, the only thing that did was the user interface.
See IEEE for instance...
Also the engineer term is a protected designation in many countries, just as doctor and laywer is...
Others are less rigorous, but can still are the practice of engineering. Software Development is one of those.
The title implies a certain amount of rigour and due diligence being applied at all stages of a design, as well as compliance with all relevant standards and regulations. This is audited by certification bodies and explicitly stated by your signature on any document or code you sign off on.
Personally I think this is somewhere that software development could head in the future, but there seems to be too much disagreement on coding best practices to standardise them, and anyway I doubt most people would be willing to pay the cost associated with this, for the majority of software.
The whole frame of mind in which I do EE is incredibly different from the one in which I do programming, to the extent that, for much of my early career, there was simply no way I could do both of them efficiently during the same day. The time of context switching was, literally, a good night's sleep. There are marked differences; the ones that spring up immediately are:
1. I spend a lot of time doing actual computation, optimizing my design on paper and attempting to predict interactions that occur due to reality not being quite like its ideal model. Some of the younger engineers frown upon this (mostly because they suck at math and think theory is for bookworms), but it's very productive once you manage to do it right.
2. Even when specifications are complete and respected to the letter, there are still differences between what you specify and what gets built. There are technological variations you must account for.
3. Better yet, you always need to bear in mind the limitations of the manufacturing process for what you design. When I think about how I'll write something, my own ability to code is literally the only limit I have to deal with. There are, of course, hard limits due to the constraints of the platform you work on (e.g. there is some hard limit to how much code you can fit in 16K of flash), but these are of a very different nature compare to manufacturing constraints. Designs must account for the limits of your technological process (e.g. you may not be able to mount some types of components on a PCB), and they must also ensure manufacturing is feasible and scalable (something called DFM -- Design For Manufacturing -- which I have screwed up a couple of times, due to my inexperience).
Overall, there's a huge gap between how much intuition and craftmanship I put in each activity.
I'm not saying this disqualifies programming as an engineering discipline; such differences may also exist between other engineering disciplines I have no idea about.
I, for one, tend to frown upon it being called "software engineering" though, mostly in virtue of these differences. I don't consider the term "software development" demeaning -- in fact, I prefer it, and I always present myself as a programmer and my job title as "software developer", even though I'm legally allowed to call myself an engineer.
For example I am getting a "Software Engineering" degree. It has all the same math and science classes as other engineering majors.
If I ever want to use my title as engineer I will be held to the same standards as other engineers.
In reality, I was barely a junior dev, and being in charge of a site that's getting millions of views was absolutely terrifying. In some ways, it was one of the best training exercises I could have. It forced me to learn things, and to learn them well. It was also total bullshit. My pay wasn't that great, and although I was working in a startup that was slowly becoming technical, had absolute control over technical decisions, and was able to turn a company that struggled with FTPing to a server into one with automated builds, regular code reviews using a new source control system (Git), and much more, it still highlighted more than anything that I really didn't have the slightest clue what I was doing.
It really couldn't have gone better for me. The company was acquired, and I landed a job at a great agency, and was able to work on enough projects to actually know what I was doing, and to see what good code looks like. I'm a mid-level developer now, with much better pay, but instead of looking back over old code and laughing, I tend to look back over the time where I led the technical side of a startup and laugh.
Can you believe that when I started, barely anyone used source control? That's what jumped out at me about your story, oddly enough. When I started the Web hadn't been invented, and the only version control packages were CVS and commercial options. CVS sucks, in case you're wondering. So did most of the commercial options.
In my own case I'd been programming and writing games for fun since I was 14, so by the time I took my first job at 22, I'd already been coding pretty regularly for 8 years. Some of that was actually for-pay, though only a few months worth. So between the experience I did have and my oversized ego, I pretty much expected the "Senior" label.
He then became the sole member of the business :-)
Well normally they only hired people with 6+ years of solid web development experience as senior engineers (just like no one today would think of hiring a senior Node.js developer with less than 5 years under the belt). But they decided to give the article poster a break for his people skills and Team Player potential.
The idea that Time Warner already had a sophisticated Web division smells like BS to me. I would accept 1997 or 1998, but not 1995.
It was not sophisticated by today's standards, but it was one of the first real magazine sites on the web. Here are some screenshots.
> The idea that Time Warner already had a sophisticated Web division smells like BS to me
the title 'senior' doesn't imply the division was sophisticated. If something smells like BS, doesn't mean it can't exist. There is a lot of BS around.
attributed to Napoleon Bonaparte
(Except the static HTML idea is a bit of a give away, no web developer would ever dare suggest a static page in our brave new world of Web X.0)
Page is static. JSON is a static file with a phone number. And use jQuery to load the JSON file.
Perhaps a whooshing sound should be made though, if I didn't get the joke..?!
Data managed in spreadsheets, layer upon layer of disconnected management, no engagement with users, very little willingness to understand software development. More spreadsheets...
Warren Buffet was spot on when he said (after investing in insurance companies): “Invest in businesses that any idiot can run because, sooner or later, one will.”
I remember finally turning down one project after failing to convince the small businessman that his site didn't need an unskippable flash intro with techno music.
Edit: I think that nowadays web 2.0 needs have been replaced with 'BIG Data'. I have a current client whose data set is less than 30 MB, but he insists that it is not just big data, but HUGE data! Which is a shame, As it is an interesting problem he has, but I will probably turn it down too.
Great advice for dealing with issues we did not consider in our estimate.
Had he charged hourly instead of a fixed price, would this project have been less shitty?
Edit: Fixed grammar. Thanks b0z0. :)
I have yet to find a customer unwilling to try to doom their own project or a compensation strategy that reliably prevents it - its just tons of work and communication. Unfortunately I'm just an okay coder and most people seem like they actually want a code talk therapist.
I worked at Prudential about 10 years ago, as a FTE. Our small division mainly ran on a bunch of custom Access reporting applications. It wasn't quite cutting it, because Access, so it was decided that we would build a portal on the company's intranet. The only problem was that we, as accidental web developers, were not allowed to run development web servers on our dev machines, because they were locked down by corporate. We had to use an extra PC that, by some miracle, had IIS, and develop against that remotely. Good times.
In addition to being funny in retrospect, it was a good lesson to me to learn that no matter how shitty your current situation, you can always improve it.
If the most critical part of a data heavy project is speccing it out, I'd say the next most important part is the data munging process...and sadly, both of these things are the most overlooked.
I'm sure if someone so desired, they could ask a specific question regarding the story either in reply to the root comment or as a root comment and expect it may be seen by the author, and possibly get a reply.
Maybe I'm just getting old.
Somehow reminds me of a co-worker wandering into my cube with a dazed look, mumbling "I just ran an 8-hour database job with the wrong data...I just wasted $64,000...".
It's like a very long function that returns nothing and has no side effects.
On Error Resume Next
on e goto end
I am confused the person stated that they were a senior web engineer but quit to work on a new thing the WWW. How can you be a senior web engineer for something brand new?
- not enough questions asked
- not listened to the customer
Do not ever start building something or proposing a solution if you don't understand the customers problem deeply enough.
My next job will be a product based company.
1. You should spend more time designing (away from the computer) so that you find a _problem_ and then come up with a reasonable solution. Instead of putting together a list of features. (see Rich Hickey's talk "Hammock-driven development").
2. Think of the sum you're going to charge for your consulting and then multiply it by 4 and charge that because you have to take risk and other factors into account.
Also, let's not forget that this was 1995 and most big businesses weren't really fully aware of the potential of the internet and the disruption on standard business models that was going to ensue...
a) Do I need the cash and is the market quiet at the time?
b) Are there some other opportunities that might result?
c) Is the hourly rate way higher than I could get somewhere else?
d) Is the tedium only short term?
e) Am I gaining some significant skills / experience?
f) Did I give my word to do the job?
If the answer to any of the above is yes, I may well accept the project or continue on with the project, otherwise I would move on.
I remember when I was working in London, I was on the same contract for 2 years. About 9 months out from the end they extended my contract and we were asked to build a prototype of a system that automated a lot of human elements of the original system we built. We built the prototype, and it was very good, but the funding was pulled and most people left the project. By that stage I was about 4 months from my visa running out, and there was no work to do. So I stayed on and did nothing but about 30 minutes of support work per day and the rest of the time worked on pet projects and amused myself. I felt a little bad about it, as I was earning $120/hr, but I may well have been screwed if I tried to find work with only a few months left on my visa.
Some executive rightly saw that paying you to render that useless would free them of that service and the need for the fee (which i bet was not turning a profit)
But, since big companies run on cargo cult... that happened.
I'm not working in real estate, but I'd guess that each referral would earn them at least something like $100 or much more - so forcing the "customer" (not really their customer since they don't sell anything to them, but only to the realtors) to call is the correct business decision.
The only WTF question is why they initiated a project that they don't want to use.
Add to this that this was back in 1995. Companies had no clue what the internet was nor what they wanted to do with it, so this kind of clueless behaviour what the customer wanted was pretty much standard for most companies up to at least 1998 - 1999.
The guy has either been tremendously lucky, or he has not worked in too many different projects / companies for the last 18 years....
I worked there for about a week before I quit in frustration.
It was the result of automatically porting a codebase written with a RAD system called Gupta Team Developer / SQLWindows. The original language supported multiple inheritance and the converted code was a huge mess of tangled interfaces trying to reproduce that. The tool generated lots of duplicated code and some monster constructs like a static class with 140.000 lines of code, with all public methods.
I still weep for my colleagues who were left to tame that mess.
In the long run it would be cheaper rebuilding the entire thing.
In two of the three cases I was converting between "the same language" but different incompatible versions of it and the original code bases had strict style guides. At the end of it everything worked brilliantly, and the code was just as maintainable as it was before the conversion.
In my experience is that language conversion projects are gnarly, and depend heavily on style guides and accurate specifications for the languages to produce good output. But these are not doomed enterprises from the start and in the end it's the quality of your convertering code that determines the success of the project.
We still rewrote the entire thing, line by line and then spent months refactoring it. It was our only choice really, so much of the original code was so unclear and all the original developers had left so it was our only hope of keeping the business logic intact.
For example, the company I work for has software developed in a legacy language with no support (Forte 4GL).
There are companies that offer Forte to Java migration, it would have been worth it because of better tools and support (even if the code was the same crap as usual :) ).
One shot code generation is usually fine (make it, run it, throw it away).
Similarly, if the target language is never going to be read or edited by a human then you should avoid most issues.