Today’s Top Tech Skills • Hacker News Board

Re: Today’s Top Tech Skills

#351

Post by benhurmarcel » Mon, Nov 25, 2019, 10:13 AM UTC

swiley wrote: post #350

benhurmarcel wrote: post #278

Earlier quoted context omitted.

It's not just about choosing the right tool from the beginning. The open-source options are often not adequate at all. I'm more comfortable talking about mechanical CAD, and in that space FreeCAD (while amazing for a free tool) doesn't come close to professional tools like Solidworks or Catia. Even for personal 3d printing projects it's really lacking, let alone for professional work.

I’m much more familiar with electrical stuff personally and my experience with that is that a lot of the commercial stuff is overdone without any useful thing to show for it (AutoCAD electrical vs XCircuit is my favorite example.) I use OpensCAD for drawing 3D stuff because it’s more intuitive to me and haven’t used either FreeCAD or Solidworks for more than a few minutes each. Is it basic drawing stuff that FreeCAD…

> Or does FreeCAD lack basic drawing features?

Yes, basically.

FreeCAD only does 3d modelling and 2d drawings, that's right. That's not what I "complain" about, this is normal, that's a CAD package. FEA is another software category.

But it's really lacking in modelling compared to professional tools like Solidworks.

Re: Today’s Top Tech Skills

#352

Post by gigatexal » Mon, Nov 25, 2019, 11:06 AM UTC

notduncansmith wrote: post #98

gigatexal wrote: post #80

Earlier quoted context omitted.

I agree. Use the right abstraction and the right number of them: I’ve yet to find an ORM that didn’t kick you in the face In terms of performance to only hold your hand with queries. SQL queries can be done in code in a sane way to avoid sql injection or you could implement stored procedures and functions to make operations more ORM-like but not pay any of the ORM tax. It’s just annoying to see the DB treated so flip…

I think HugSQL[1] (Clojure library) has really opened my eyes to what DB interaction should be like. It’s not exactly an ORM, but it protects you from SQL injection and makes it convenient to leverage the capabilities of your SQL database. Also, his name is Usain Bolt[2]. [1] https://github.com/layerware/hugsql [2] https://en.m.wikipedia.org/wiki/Usain_Bolt

Sure I am not saying crafting queries explicitly and preventing sql injection etc in code is elegant but it can be done and you can write super thin abstractions over the boring bits and still maintain a ton of power over your queries and know exactly what is going on without having to add another dependency.

The one huge win for ORMs in my mind is the standing up of and the iteration of schemas, defining a schema and then summoning a database in alembic vernacular is really neat whereas one would have to manually manage a set of init scripts and migrations oneself.

In the end there's no really clean way to do DB maintenance and work it's just work and has to be done, imo.

Re: Today’s Top Tech Skills

#353

Post by dennis_jeeves » Mon, Nov 25, 2019, 12:20 PM UTC

brightball wrote: post #336

dennis_jeeves wrote: post #329

Earlier quoted context omitted.

Brightball, how many years of coding/sql/developer experience do you have?

Going on 20

How much time would you think, the (+)average programmer, say with 10 years experience needs to learn _basic_ sql, along with the HAVING clause, assuming they have never learnt sql during their entire working career? ( we are talking RDBMS concepts from scratch. like Primary keys, normalization etc, and finally sql).

(+) average= meaning the programmer should be able to say 'solve' the FizzBuzz under comfortable conditions. Or say add the first n items in an integer array etc...

Re: Today’s Top Tech Skills

#354

Post by cushychicken » Mon, Nov 25, 2019, 1:17 PM UTC

smnrchrds wrote: post #231

cushychicken wrote: post #223

Earlier quoted context omitted.

>Outside of programming, this is the norm. The number of free and/or open-source tools available to a mechanical engineer or an electrical engineer are infinitesimally small and it is almost impossible to do a serious engineering project with only free tools. >Since this is quite lucrative for the companies making those tools, I can only imagine tech companies would be more than happy to lead us to a future where sof…

> I wonder sometimes about the fact that SW engineers are capable of making their own tools in a way that we are not. Do you think this helps to combat some of the super high pricing associated with their tooling? I can only speculate, since I am not a software engineer, but I think part of maturing is things get more complex and making things more difficult and expensive. Thirty years ago, someone could say "Fuck it…

>I think part of maturing is things get more complex and making things more difficult and expensive.

I agree. I think this is a great, succinct description of the underlying "why". It's a moat, to use PG's term for it.

I could make a better Altium. It's just that Altium has a few decades head start on me. XD

Re: Today’s Top Tech Skills

#355

Post by wyclif » Mon, Nov 25, 2019, 1:51 PM UTC

jpalomaki wrote: post #200

_bxg1 wrote: post #36

Earlier quoted context omitted.

Then it's disturbing that they're so non-standardized. I personally wouldn't want to spend a bunch of time becoming an expert in a skill that only applies to one company's physical servers.

If we can learn anything from history, I wouldn't hold my breath waiting for the standardization. Just look at situation on the operating system side. Different flavors of Unix, VMS, z/OS, Windows. Sure there are concepts that apply to all of them, but if you want to be an expert you really need to go deep on the vendor specific things.

Anecdotal: my cousin is a sysadmin and he recently took a certification class for z/OS. He says it was probably the best career-enhancing step he's ever made.

Re: Today’s Top Tech Skills

#356

Post by yourapostasy » Mon, Nov 25, 2019, 1:59 PM UTC

UweSchmidt wrote: post #266

freehunter wrote: post #225

Earlier quoted context omitted.

It's nothing to do with the hosting or portability and everything to do with talking the language and navigating the interface. You can set up a bare VM and install your own OS and manage everything yourself and avoid any kind of lock-in, but if you don't know how to navigate AWS your entire operations collapses with bad IAM policies, world-readable S3 buckets, and VPCs that let the entire world in. On the other hand…

All true. Point is that it used to be that a key piece of intrastructure was based on "open", general tech, and now it's not, and that's regrettable.

Not just regrettable in a philosophical sense, but in a real, break-fix, operational speed, meeting multi-million dollar per night, getting-shit-done-for-real bottom-line sense. There is a direct correlation in observability in open and closed tech components of a stack. If you have the tech talent to dig into open stacks, break-fix resolution is faster with more granular traceability (and observability depth is unmatched), your team's understanding of the data and process models is more thorough, you gain a better understanding where the design limits lay or at least their directional value, and you have a better overall sense of control over the solution.

That "if you have the tech talent..." qualifier is the big one, though. I see very few companies who recognize how to attract and retain that talent level. IMHO, out of the more than 200 companies I've consulted at or sold deeply enough into in the sales cycle to see enough of how their sausage gets made to form an opinion, probably no more than 1:100 do this. So we end up here, where most companies are content to hire well below that level, buy closed tech stacks, and then play support-tag while users sit unhappy. Plays well politically, but it's a mess for delivery service levels.

Re: Today’s Top Tech Skills

#357

Post by brightball » Mon, Nov 25, 2019, 2:48 PM UTC

dennis_jeeves wrote: post #353

brightball wrote: post #336

Earlier quoted context omitted.

Going on 20

How much time would you think, the (+)average programmer, say with 10 years experience needs to learn _basic_ sql, along with the HAVING clause, assuming they have never learnt sql during their entire working career? ( we are talking RDBMS concepts from scratch. like Primary keys, normalization etc, and finally sql). (+) average= meaning the programmer should be able to say 'solve' the FizzBuzz under comfortable cond…

Largely depends why you ask? I get the impression that most people have taken this to be a pass fail type question in an interview and that’s where the contention is coming from.

My interviews are conversations to get to know you, your background, your professional interests, how you think about problems and how closely your resume lines up with those conversations. I like to get people talking about their work to see where their energy level goes.

When we start talking through a hypothetical data problem there are people who will describe the problem from the UX perspective, the app code perspective and the database perspective. The question prompts that portion of the conversation.

Re: Today’s Top Tech Skills

#358

Post by dennis_jeeves » Mon, Nov 25, 2019, 2:55 PM UTC

brightball wrote: post #357

dennis_jeeves wrote: post #353

Earlier quoted context omitted.

How much time would you think, the (+)average programmer, say with 10 years experience needs to learn _basic_ sql, along with the HAVING clause, assuming they have never learnt sql during their entire working career? ( we are talking RDBMS concepts from scratch. like Primary keys, normalization etc, and finally sql). (+) average= meaning the programmer should be able to say 'solve' the FizzBuzz under comfortable cond…

Largely depends why you ask? I get the impression that most people have taken this to be a pass fail type question in an interview and that’s where the contention is coming from. My interviews are conversations to get to know you, your background, your professional interests, how you think about problems and how closely your resume lines up with those conversations. I like to get people talking about their work to se…

>I get the impression that most people have taken this to be a pass fail type question in an interview and that’s where the contention is coming from

Precisely. And why not? I have my fellow developers do that ( ask trivia and label the interviewee incompetent, if he cannot answer it) , and most people who have reacted to your post have also probably seen that.

Anyway humor me and tell me how much time it would take?

Re: Today’s Top Tech Skills

#359

Post by brightball » Mon, Nov 25, 2019, 4:39 PM UTC

dennis_jeeves wrote: post #358

brightball wrote: post #357

Earlier quoted context omitted.

Largely depends why you ask? I get the impression that most people have taken this to be a pass fail type question in an interview and that’s where the contention is coming from. My interviews are conversations to get to know you, your background, your professional interests, how you think about problems and how closely your resume lines up with those conversations. I like to get people talking about their work to se…

>I get the impression that most people have taken this to be a pass fail type question in an interview and that’s where the contention is coming from Precisely. And why not? I have my fellow developers do that ( ask trivia and label the interviewee incompetent, if he cannot answer it) , and most people who have reacted to your post have also probably seen that. Anyway humor me and tell me how much time it would take?

Learning the concepts? A few hours

Using the concepts in how you naturally think about problems?

That will only come from experience. I can't say exactly how much but I'd imagine something in the realm of 6 months minimum of applied usage to different problems.

Re: Today’s Top Tech Skills

#360

Post by freehunter » Mon, Nov 25, 2019, 4:40 PM UTC

yourapostasy wrote: post #356

UweSchmidt wrote: post #266

Earlier quoted context omitted.

All true. Point is that it used to be that a key piece of intrastructure was based on "open", general tech, and now it's not, and that's regrettable.

Not just regrettable in a philosophical sense, but in a real, break-fix, operational speed, meeting multi-million dollar per night, getting-shit-done-for-real bottom-line sense. There is a direct correlation in observability in open and closed tech components of a stack. If you have the tech talent to dig into open stacks, break-fix resolution is faster with more granular traceability (and observability depth is unma…

As a business you need to decide what your core competency is and play to that. If you're a food distribution company do you really want to hire staff to "dig into open stacks" or do you want to just call the vendor and let them sort it out?

The reason enterprises can't hire that kind of talent is because they don't want to. The reason they can't retain that talent if they do accidentally hire it is because that kind of break-fix resolution

1) doesn't happen that often so the people get bored

2) is frowned upon by management because those people have actual jobs to do

and

3) is the entire reason they pay a support contract to their vendor

And $50k/yr in support costs is a lot cheaper than hiring the world's best DBA, world's best Linux resource, world's best Java programmer, world's best infosec analyst, world's best architect, world's best SAP resource, the list goes on and on.

The job of enterprise IT isn't to be the best at anything, it's to be stable and predictable.