The shittiest project I ever worked on
171–180 of 187 posts
Re: The shittiest project I ever worked on
#172Although it's a fun read, it's a classic example of diving into coding without giving a project it's due diligence. There's nothing that's derailed my projects more consistently when I started out as not understanding the user's needs. They'll never tell you what they want, only what they don't want after you deliver something. I think that's the key difference to an experienced dev/BA. One who can actually sit with…
Kind of agree with you and OP, so let me add to the discussion with the caveat that YMMV etc. Some of these points may overlap with comments by fellow HNers in these threads. 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…
Re: The shittiest project I ever worked on
#173"In 1995 I quit my regular job as senior web engineer for Time-Warner and became a consultant developing interactive content for the World-Wide Web, which was still a pretty new thing at the time." 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? Just nitpicking...
Re: The shittiest project I ever worked on
#174> In 1995 I quit my regular job as senior web engineer You had the job title "senior web engineer" when the web was 4 years old. That's pretty cool.
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.
Re: The shittiest project I ever worked on
#175Earlier quoted context omitted.
The distinctions you are making are mere tendencies. Automotive engineering, for instance, requires everything on your list of software development traits—in spades. 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.
I think the big difference is that the civil engineer doesn't actually lay the cement himself, but the software engineer does. This has a lot of ramifications about how each approaches the problems and sees themselves in context.
#have argued, actually
Re: The shittiest project I ever worked on
#176Earlier quoted context omitted.
Or you could have moved to the petrochemical industry, where you would have been paid more than any software engineer anywhere...
@Nostrademons 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.
Re: The shittiest project I ever worked on
#177My next job will be a product based company.
Re: The shittiest project I ever worked on
#178Re: The shittiest project I ever worked on
#179Earlier quoted context omitted.
I'm not convinced. Care to make a case?
The degree of responsibility is vastly different. Engineers are licensed, and can (and often are) sued for professional negligence. Failing to do your job adequately means you'll be stripped of your license and prevented from practicing engineering.
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.
Re: The shittiest project I ever worked on
#180Earlier quoted context omitted.
Kind of agree with you and OP, so let me add to the discussion with the caveat that YMMV etc. Some of these points may overlap with comments by fellow HNers in these threads. 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…
I rarely comment here, but your excellent post deserves to be recognized. I'm someone who has thought a good deal about starting a consulting company but never managed to convince myself the risk/reward numbers would work for my life situation. Your richly detailed and honest perspective is much appreciated. Thank you.
Should you be comfortable, I'll be very glad to keep in touch with you. My e-mail is on the GitHub profile.