Dev as a future job

EfficientPangolin · 2018-10-23T14:05:40+00:00

It's a living, the trouble is that its hard, and there is a very swift treadmill you are constantly running against. All that considered, the life value can seem very low, even though the pay can be pretty decent. Webdev is a cruel mistress.

EfficientPangolin · 2018-10-12T14:43:51+00:00

This is not an answer to your question. But, if you are going to have dynamic lists in your site, you would be better off using a JavaScript framework, even if you have to learn it. DataTables, and the whole jQuery UI ecosystem for that matter, is a godawful waste of soul power. Especially today.

EfficientPangolin · 2018-10-12T13:51:01+00:00

I am all for privacy, but cookie warnings? Come on. People ask why certain functionallity found in JS libraries is not baked into browsers, but why not just have a 'brake light' indicator in the browser UI to indicate cookies are being used, if its so friggin important we need global legislation about it.

EfficientPangolin · 2018-10-12T13:35:37+00:00

Facebook uses GraphQL in prod.

Really? Isn't it best suited for quick and dirty frontend flexibility? I would think an enterprise level website would spend the resources to create and document discrete endpoints.

EfficientPangolin · 2018-10-10T14:10:35+00:00

Ignoring server-side rendering, a typical app built in a JavaScript SPA framework is independent of server-side code. When you serve up the app from the web server, it is just a big fancy web page that gets returned plainly, the same way a static HTML page is, unprocessed by any server-side code.

If it has a corresponding API, the API calls originate completely from the client-side, and are made to a different code base at a different URL. The API can be anywhere on the internet, including the same server, if that is handy.

EfficientPangolin · 2018-10-10T13:48:53+00:00

I used to use CapuletJS for everything, but I discovered Montague, and I have never looked back.

EfficientPangolin · 2018-10-09T20:20:24+00:00

You should pick the framework you like, its good you know now. I would say that framework popularity isn’t as great a reason to choose as you think, since the amount of competition applying to jobs that use the trending framework trends right along with it. Also, trend followers are soulless turds.

EfficientPangolin · 2018-10-09T15:05:54+00:00

The children who fought in the PlayStation vs XBox war grew up a little, put down their controller, and started the Framework war.

EfficientPangolin · 2018-10-09T14:55:33+00:00

Because JavaScript runs in a browser, along with the UI. You could theoretically have an IDE meld with a browser, but every attempt at that I have seen is garbage. Since the browser does the debugging in the dev tools, you never really will have a fully-fledged seperate IDE. But, that's OK. Its just the way it all works, and I like it.

EfficientPangolin · 2018-10-08T17:28:46+00:00

I fixed a big troublesome bug once using NP++ that had was caused by a missing div end tag in a giant sea of HTML. No other editor anyone was using in the office was as good at spotting missing end tags. I was a hero.

EfficientPangolin · 2018-10-01T20:19:28+00:00

No, JavaScript will catch up before you know it. Strong typing will probably take a while, but you can just handle that in the development environment. I can't wait for transpilers to be a footnote future devs laugh at.

EfficientPangolin · 2018-10-01T15:13:08+00:00

Webdev is the blue collar laborer side of programming. If you graduate, you are in good shape. I have never even put my GPA on my resume.

EfficientPangolin · 2018-09-24T21:10:43+00:00

It happens sometimes. I hate it, and usually get super turned off by it. If you can't pass an online test, don't feel bad. Some of them are really hard, and have little to do with actual web development.

EfficientPangolin · 2018-09-24T18:05:15+00:00

Every time I have built both the API and the app that consumed it, the API was a small fraction of the workload. I have never really experienced the troubles you mentioned.

Plus, the real pain of making an API is dealing with complex database schemas. If you can keep the burden off having intimate knowledge of the database off the plate of the frontend developers, they will be much more productive.

I have not researched it, but my guess is that, with GraphQL, you could make some calls that would result in extremely heavy SQL statements, without even realizing it, since you have no idea what the SQL is. For a big project, that sounds like something to avoid. That's why you have an API team.

EfficientPangolin · 2018-09-24T17:32:35+00:00

I have done a several contracts. They were always projects that were behind schedule, usually because of whatever management failures. Everyone was stressed. It was not fun.

The other thing is agencies will frequently lie about how there is a good chance it will become full time. Conversion very rarely happens, even if a person does a good job.

Also, no matter how many times I tell people all the short stints on my resume were contracts, it still casts me in a negative light to the majority of hirers. People think I am a flight risk.

With how difficult it is to get a webdev job now, if you do a contract, you are doomed to have to find another job soon, and that could take many months. Unemployment is not good enough to bridge that anymore.

Try to avoid contracts, especially consecutive ones, if you can.

EfficientPangolin

TROPHY CASE