At my company: Inteviewer: So you are a carpenter? Carpenter: Yes. Inteviewer: Can you make a start fixing that leaky roof over there? We will monitor your skills and might hire you. Carpenter: Done.
I think this is a great way of hiring people. With certain caveats of course: your company must give candidates, preferably one at a time, an honest chance and not exploit them to get leaky roofs fixed for free.
If Carpenters Were Hired Like Programmers (2004)
101–110 of 123 posts
Re: If Carpenters Were Hired Like Programmers (2004)
#102Earlier quoted context omitted.
Haha. The references to Indian developers were funny. But this joke works even if you replace Indians by other developers in US. Remember healthcare.gov fiasco?
It doesn't really. That job was poorly done AND expensive.
I think many people miss the fact that boring jobs with low wages will not attract talented programmers. Same holds true when you outsource jobs. Send interesting jobs and pay for good Indian programmers for quality results.
healthcare.gov was a clusterfuck not because it was complicated (a typical data integration task with a query layer) but because of the quality of programmers and managers working on it. Later after political and international embarrassment, a crack team of exceptional programmers was assembled (on leave from major tech companies) to fix that website.
Re: If Carpenters Were Hired Like Programmers (2004)
#103Earlier quoted context omitted.
Software is software. The paradigms are the same. The languages have the same roots. What is culture for a programming language anyways? Sure, the tools and frameworks are different, and every language has it's own quirks and uniqueness but they're not as different as you make it sound. If a developer is skilled, these are small differences.
> The paradigms are the same So Clojure, Java, Javascript, Haskell and Ruby are all basically the same? I think damage can be done hammering different languages into the same methodologies.. > If a developer is skilled You suggest skill is generic. If a programmer is smart they can learn new paradigms. Projecting the paradigms they are used to onto new domains can produce problems, least of all the standardisation.
Re: If Carpenters Were Hired Like Programmers (2004)
#104Earlier quoted context omitted.
>> what's the most popular kind of wood right now? Exactly. We're putting together a team to make a sink using it. In the second phase we will use wood to build a toilet. Interested? >that's actually kinda fun! (years later) ... and that's how I ended up installing toilets in exchange for equity.
They make boats out of it, so why not? Slap some marine enamel or polyurethane on that terlet! Or use pitch for that old-time feel.
Will the price they pay be higher than the cost to build it?
Re: If Carpenters Were Hired Like Programmers (2004)
#105Re: If Carpenters Were Hired Like Programmers (2004)
#106Could be updated: Interviewer: Could you give us a couple of examples of carpentry projects you have completed in your spare time, and do you have a portfolio of projects you have worked on outside of your day-to-day job? Carpenter: Uhm, what do you mean? Interviewer: I mean like carpentry in your community, or a project you've completed to hone your skills outside work? Carpenter: Oh, I am usually quite tired of ham…
Carpenter: No, it's all internal to my previous employer.
Re: If Carpenters Were Hired Like Programmers (2004)
#107In the US, for significant, long term financial security, it is close to essential to start, own, and run a business and make it successful.
As a young person in a hot field, being an employee can look good, but usually too soon, well before retirement, being an employee is awful.
For computing: If computing is valuable, and of course it can be very valuable, then somehow a person in computing needs not to be an employee but to own their own business and make it successful.
Broadly a key to being successful in business is to sell directly or nearly so to the end user. So, in computing, for the business, develop a product or service that sells to, gets revenue (or eyeballs for ad revenue, here and below) from, the end user. For this, pick a problem the end users want solved and that you can solve with computing, have a barrier to entry, ..., and get the revenue. Try to have the product, service so that the number of end users times the net revenue from each makes a good business, e.g., gets you some good financial security.
There is a huge, but easily overlooked, difference: (A) As an employee, you are getting all your money from your employer, only from your employer, and they know exactly how much money you are getting. If the employer concludes that they are paying you more than necessary, then they will work to pay you less. It's super tough to get good financial security as an employee from an employer. (B) As a business owner, you are getting money from usually at least a few and often many users, and usually the users have no idea what your profit margins and net revenue are, and, even if your revenue is high and they know it, there's next to nothing they can do about it. So, if you can find a way to get a lot of net revenue, then you have a good chance of some good financial security; the users have little or no way to keep you from the revenue.
In simple terms, if your work is valuable, then you should get a lot of money for it. Being an employee is a poor way to get that money; instead, your employer gets the big bucks. So, own your own business and keep that money, the big bucks, plus what would have been your employee's salary, for yourself.
In the terms of the OP, there are some huge advantages in owning your own business. To illustrate this point, I will draw from the best example I have, my startup:
I saw the problem, did some applied math technical work for a solution, designed a Web site as the means of delivering the solution, designed the rest of the software, learned a little HTML and CSS (but no JavaScript -- didn't need it) and Microsoft's .NET Framework (for writing applications software), ASP.NET (for Web pages), ADO.NET (for programming use of relational database, e.g., Microsoft's SQL Server), typed in 24,000 programming language statements in 100,000 lines of typing, and am going live on the Internet ASAP.
Well, all I had to learn was just what I needed, and for more I didn't learn it. So, e.g., compared with C#, I prefer Visual Basic .NET as easier to learn, teach, read, write, and debug and otherwise, as access to .NET, etc., essentially equivalent to C#. E.g., C# has much of the deliberately idiosyncratic syntax of C, a language designed to be really sparse and low level and to compile and run on a 5 KB DEC mini computer; and C++ was originally just a pre-processor to C (in those days, language pre-processors, e.g., RATFOR, were popular). So, for me, to heck with the C# syntax, and I have not studied C# and have yet to write a single line of it.
Yes, apparently Python is quite useful and very popular. As I understand it, it is interpretative which means it can be easier to use but slow. As I understand it, Microsoft's Iron Python is compiled and provides good access to .NET. As I understand it, Python has some really nice software "packages". Maybe in time I will need or be able to make good use of Python; then I will learn and use it. But so far I've had no use for Python and have not used, learned, or even installed it.
Python is just an example: I just learn and get needed experience with the software tools I need for my startup, and that's much, much less than would would be needed for the scenarios, in my experience accurate as a parody, in the OP.
Now what I concentrate on learning is not software tools (so far I have what I need and from early in my career much more) but what I need for my business, e.g., now, getting good initial data, publicity, and products (processors, motherboards, main memory, mass storage, etc.), and server construction, monitoring, maintenance, and administration.
E.g., for my servers, can I use AMD Ryzen processors with ECC (error correcting coding) main memory and Windows Server 2016 (that wants ECC main memory)?
So, I'm 100% owner of my startup. Thus, if there is good value in my software, then I will get that all that value instead of some only some small fraction of that value with some employer getting the rest.
So, to respond to the situation in the OP, I suggest that people who can write valuable software should start their own business, own 100% of it, pick a good problem, write valuable software for a valuable solution, and collect the big bucks themselves.
E.g., the OP has the employer asking really dumb questions. Why should a good software developer put up with such nonsense? They shouldn't and, instead, should have their own business. Such nonsense is not a good path for either the employer or the employee to make much money.
Re: If Carpenters Were Hired Like Programmers (2004)
#108The equivalent the other way. If programmers hired like carpenters are hired made a table: "How long will it take to make this table?" "3 weeks. But we're going to try using this new kind of leg because it's easier to replace with another leg if you don't like it. So it may take 5 weeks." 5 weeks pass "Is the table done?" "Well, no, not really. But now you can have four different legs if you want to. We've also got t…
"YAGNI"
"Where is the fourth leg?"
"Over there, across the street. See?"
"...Why?"
"Microservices. When you put something on the table that needs the fourth leg, you use these pipes to temporarily connect it."
Re: If Carpenters Were Hired Like Programmers (2004)
#109Earlier quoted context omitted.
Too much emphasis? Most recent graduates don't even have a GitHub profile. They get jobs because they graduated. It's totally fine. If you did not graduate, you better have some projects to show though.
That's interesting. For companies I have approached recently it was the first question they asked. Maybe it depends on the kind of company (for me it was mainly start-ups).
Re: If Carpenters Were Hired Like Programmers (2004)
#110Earlier quoted context omitted.
> The paradigms are the same So Clojure, Java, Javascript, Haskell and Ruby are all basically the same? I think damage can be done hammering different languages into the same methodologies.. > If a developer is skilled You suggest skill is generic. If a programmer is smart they can learn new paradigms. Projecting the paradigms they are used to onto new domains can produce problems, least of all the standardisation.
> So Clojure, Java, Javascript, Haskell and Ruby are all basically the same? Nice try, but we were talking about PHP and Java. Also, for instance, functional paradigm is the same for all functional languages, which is what I meant in the first place. > You suggest skill is generic. I'm suggesting the developer understands the OOP paradigm, knows about design patterns and isn't confused by the small differences in syn…
You started by saying "Software is software", you didn't mean this to imply all languages are similar?
> functional paradigm is the same for all functional languages
So Haskell and Clojure are similar?
> understands the OOP paradigm, knows about design patterns
Design patterns differ between languages. And OOP principles too. I don't want to see ConfigurationBuilderFactory classes in my Python code.
> I'm not going to write generic comments that cover every case
You only claimed "Two languages using the same paradigm are closer to each other" - but this seems tautologically true, depending on how you define "paradigm". Many OO languages differ in ways significant to the Java way of OOP.