2020-03-22 09:06:54

@Camlorn:
You use c professionally?

I was surprised after I read that. because I do no c, (well, as much as I could, before I got dropped by the guy who was teaching me, nowadays I just solve problems on the sites like codeabbey using that language,) and am now currently learning java. according to the new guy who is teaching me, c does not have much of a scope.

I don't think overall he is right. since even the jvm are written in c, (or maybe with some c++,) but he might be right about that here in India.

Thumbs up

2020-03-22 13:34:10 (edited by Munawar 2020-03-22 13:40:48)

I'm in disagreement with the CS degree requirement. Most people I know who have CS degrees don't need them. If you're looking for programming alone, it's better for you to go for an applied programming degree. You'll steer clear of the theory side of things. Keep in mind CS is a degree under Mathematics, so unless you plan for a science-oriented organization, most of the knowledge you gain will be wasteful. For example, for web development, you don't need a CS degree. If you're going to be working on block chain technology, then CS is for you.

Since you've started out as a hobbyist developer and are aiming to make money fast, go for applied programming. The problem with CS is you pretty much max out quickly.

For languages, I'm in agreement with the general consensus here: anything Javascript related is worth your time. NodeJS is now very popular, and for good reason: it allows a former front-end developer to become a back-end developer quickly.

SQL looks like it's being deprecated. Traditional databases are no longer able to handle the demand of modern applications (even Microsoft doesn't use SQL Server for their more recent applications, in favor of Redis and other in-memory databases.)

C++ has a specialized purpose. Unless you need it, no need to learn it. We used it when working on block chains, but otherwise you tend to spend a lot of time doing things in C++ that high-level languages do for free, so it's not seen as an economically friendly language (your managers don't want you worrying about low-level stuff when all they care about are results, so RAD (rapid application development) is where it's at.) This is why Node in particular has gained so much popularity: you can spin up a server in a matter of seconds without even having to worry about tinkering with Apache configurations.

In today's market, it's all about results. How fast can you get something running? And for this, applied programming is your best option.

@Ethin: with respect to your job search, hang in there. Do make sure to have your Github updated and have a project readily available to showcase, preferably in a RAD language. People want to see how fast you can go from 0 to 100, not that you developed this and that algorithm because they'll say "but...it took 2 months." Remember: your time is their money.

I've seen a drastic shift in hiring requirements just over the last two years and have pretty much been in the job force since the days of .NET. Back then, yes, you did get hired for your C# and database experience as I did, but that's not the case now. Things are changing much faster than they did when .NET was new. We're moving to a more hands-off approach to programming. Indeed, I think even the idea of sitting at a keyboard and hammering out code is becoming deprecated over time as we move to more low-code and no-code solutions. Remember when Visual Studio came out with their Form Designer and you no longer needed a designer to code your look and feel for you? This is where the programmers' market is heading.

Thumbs up

2020-03-22 17:09:26

@26
Yes, but I had to try.  C is still used in some applications, though most jobs don't use it.  Consider how many people write the JVM, versus how many people just use it.

There will always be C/C++ jobs, but it's sort of a constant number of jobs that doesn't grow very fast.  Embedded systems, mobile apps, OS work, games, and a few other domains need it.  But in terms of getting a job it's certainly not the way to go.

I went out of my way to start making that my career because I enjoy systems-level work and had the resume to give me a fighting chance.

@27
First: the CS degree is worth it.  It isn't helpful on the job, but it gets you in the door lots of places, and there are companies who do actually care about that math.  Do you need it: as I said, you don't.  But it is a almost guaranteed path to a job.

Second: SQL is as strong as it's ever been.  Postgres scales at least as far as MongoDB these days, and Google and Amazon have both bought into SQL for their big data offerings (Google BigQuery).  Additionally cassandra exists and is used by at least Netflix and Apple, and scales to petabytes of data.  And when I did the job search I interviewed with a company called MemSQL which is used by at least Comcast.  There's also TiDB, which scales quite far and has at least one terabyte-scale client in China.

Uber uses MySQL for all of their ride tracking.  I'm not sure where you got the idea that SQL doesn't scale for modern applications, other than perhaps that SQl Server itself has always been behind the curve.  Modern Postgres is a superset of MongoDB with roughly the same performance: I have personally seen a single-node, non-sharded Postgres handle 10000 writes and 100000 reads a second, that setup probably scaled further but those are the numbers I can say with a straight face, and it definitely scales further than that if you start deploying it properly.

How this looks in practice is your permanent storage ends up being something like SQL, then you grab Redis for a cache, something like Rabbit for the job queue, etc.  At the very largest scale yeah, you maybe use something else, but that usually ends up being a custom database specific to your company that your company developed for internal usage.

So, my point.  The choice here is between learn SQL, which is used by at least 5 databases and has been around for literally 30 years while still going strong, and gets usage at companies of all sizes, from the smallest web site contractors to the big players like Uber, Netflix, and Apple, while also being used in almost every web framework ever.  Or go learn today's database of the month because it "scales better" or whatever the claim is, only to have your knowledge be outdated in a couple years because rather than learn something good for your resume, you learned something specific to a small subset of problems that only the largest companies even have to care about in the first place.

My Blog
Twitter: @camlorn38

2020-03-22 20:08:08

@28: SQL is good for relational data but it has a high maintenance cost. Modern applications are moving away from stored procedures and database developers to more adaptable solutions as low-level details get abstracted away for the purposes of RAD.

CS is a great degree, but the problem is that programmers today are plumbers, and CS teaches you to engineer. So in the interest of OP's original question about money, applied programming is their quickest hassle-free path. We're talking about quick gains here, not long-term achievements. So yes, today's DB is very much relevant to OP.

One of the major issues with relational databases like SQL is it's inability to adapt to the constantly changing nature of applications. Constraints are great for data integrity but they come at a maintenance cost due to migrations and requirements changing. This is what I mean when I say these traditional legacy databases don't adapt well to modern apps.

We stopped using SQL solutions long ago where I work and have since been using more stream-oriented databases like Elastic Search and Redis. I was part of that push to move away from the idea that we must write complex and often times convoluted queries to achieve simple things. That's no longer required in today's programming world. Redis can do far more than just cache management; I use it now to power one of the applications I've written at my company and have seen a 30X decrease in delivery time. SQL is not good for large data applications where you need to scan millions and millions of rows, without periodically pruning the database. With many no-SQL solutions this is no longer an issue, and your queries are easy to understand JSON documents. Much simpler and less time consuming, again, for RAD.

Thumbs up

2020-03-22 21:33:43

@28 Cassandra is a NoSQL database. That is why it can handle such a large volume of writes and process petabytes of data. Try using its CQL to write queries like you do in SQL and without understanding the small subset of queries it will handle well and you will get atrocious performance.

But I fully agree that SQL is by no means deprecated and will be around probably for another 50 years. relational db systems are incredibly versatile and general purpose, although they just dont scale well for huge datasets where a distributed solution is needed. Still basically all companies big or small use them and will continue to use them, so it is a vital skill for any back-end developer.

At the same time, distributed cloud native NoSQL databases are more and more relevant every day and there is great lack of skill in this novel area and from what I am looking at job listings, companies are desperate for experts and will pay a lot of money to hire them, so getting into Big Data right now is really good career strategy.

Thumbs up

2020-03-22 22:13:58

@29
This isn't the place to go into this in detail but suffice it to say I disagree.  Elasticsearch is useful for the right sort of problem, and I've personally written what might be the world's most convoluted job queue on top of Redis.  But SQL is just an expression language.  It doesn't say anything much about what's underneath.  And it does scale fine for anything a junior is going to be doing.

I'm not saying that you, personally, have chosen the wrong tools for the job.  But I will say that if you found SQL difficult to deal with you may have been choosing the wrong tools for SQL.  I've been watching a friend of mine take off like a rocket with Django.  It's not hard to do basic to intermediate stuff with it, and if you choose the offerings that let you do advanced stuff with it you can do that as well.

The trade-off is faster specific sorts of queries with noSQL and possibly faster writes, but losing the generality and usually the transaction guarantees.

I think going from "I used Elasticsearch for a problem and Microsoft decided not to use SQL Server for something" to "SQL is deprecated and you shouldn't learn it" is a very big jump indeed, and the fact of the matter is that mostly people are using SQL.  As I said even Uber.

@30
Cassandra is kinda sorta NoSQl except that CQL is an SQL subset with a couple constraints.  If someone is familiar with SQL and is talking to a Cassandra shop (rare as those are), I'd bet on it helping them get in.  Describing cassandra as "An SQL database but you can't..." is honestly very apt.

My Blog
Twitter: @camlorn38

2020-03-22 23:27:30 (edited by Ethin 2020-03-22 23:33:19)

Agree with 31. SQL, itself, is just a language (specified in ISO/IEC 9075). Though the standard does specify various parts of the system, I doubt it specifies what the system should do internally for optimization of its processes; its more likely to specify an abstract method of operation, like the C standard does. If you can't figure out how to use SQL for a particular task, or the way your using it is convoluted, then: (1) SQL isn't the right system for your particular task; or (2) you lack the necessary knowledge to make the task your doing easier in SQL. (There's a 3rd point I was going to add, but I can't think of it now. Damn.) Also, just because MS isn't using SQL for one particular task does not mean that SQL is obsolete or that they're not using it for other systems. We, after all, don't know MS's entire infrastructure; I guarantee you their using SQL somewhere because anything like No-SQL would be overblown. (Side note: I'm no expert on databases. Take this with a grain of salt.)

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.

Thumbs up

2020-03-23 23:37:00

@Ethin: I've been using SQL for at least fifteen years now and still find the no SQL alternatives to be much cleaner to read. I was able to take a UI developer and turn them into one of my main database supporters over the course of less than a month and this has a lot to do with the no SQL alternatives because you don't need to know set theory to make effective queries. So it's a lot easier for the younger crowd to pick up and run with it. That's why I'm in favor of it. Another major advantage of newer no SQL systems is they come with pubsub natively supported, along with streams. This helps immensely in large data applications where SQL's performance tends to drop.

SQL is good for data integrity as I wrote earlier, but for a lot of data crunching applications it simply can't hold up. At least MYSQL and MS SQL can't. I have heard of an SQL implementation on top of Redis but I'm yet to try it.

Thumbs up

2020-03-24 00:44:38

Erg. Come on.  I have a friend who doesn't even understand O(n) and who has trouble with algebra, who wasn't programming as of 3 months ago, and whose background is in political science dealing with SQL fine.

And as I already said: BigQuery exists, TiDB exists, and MySQL scales far enough for Uber.  Postgres also scales far enough for Uber; they left it because of backup features that only MySQL had (but now Postgres beats MySql on those features, because that's how this stuff goes).

You don't need to know set theory for any of it.  The optimizers just handle it for you.

I've already said that I've seen SQL scale, *when deployed improperly*.  When deployed properly it scales much bigger than that system ever did.

You only need the more advanced features of SQL when you do more advanced things that non-SQL databases can't do. Tables and a basic where clause are dirt simple.  Joins are a bit less simple, but then most of the modern NoSQL databases suck at joins.

Colleges teach this as set theory, because they're colleges and that's what they do.  But if you just step away from that and teach it as a translation from a Python for loop to SQL, you can get someone going with it almost instantly, and the SQL compilers are able to produce much better code.  You don't have to hand migrate, there's a reason ORMs exist.

You're complaining about this, but in a way that shows you don't actually know it, then telling people not to learn it because it's hard and not scalable, even though it's one of the most commonly used tools out there and something where having experience in it counts for something in any backend job interview.

My Blog
Twitter: @camlorn38

2020-03-27 17:09:33

just a question, is it possible for  a blind person  to get a job  on  cyber security? and if so, what kind of  experiences you need? programing languages, server  management, etc...

And as anyone who's gone mountain climbing knows ,The serene snow-covered peaks that look so tranquil from a bdistance, Are the deadliest
sound is my vision

2020-03-27 18:12:46

@35
I don't personally know anyone, but I don't see why not.  However cybersecurity is a really big field.  You might have trouble if you go down the route of administer a bunch of Windows machines for some university, but nothing stops you i.e. researching X86 vulnerabilities.

Also, from what little awareness I have of that field, you'll probably need a college degree or somesuch in it.  I don't think that's such a "I learned this on my own, hire me" sort of thing--when you start throwing the word security around people want to see credentials and certifications.

My Blog
Twitter: @camlorn38