|
Your current project sounds decent; you are keeping your .NET skills fresh while learning something new. I don't think you have to turn down everything not .NET related. This assumes that people are sane and won't think that your .NET skills have disappeared because you were working on a Wordpress focused project for a few months.
It might also be useful to think about new skills beyond how they'll help you land your next job. From what I've seen, the Wordpress plugin landscape is woefully underserved by good developers. And there are some pretty bad plugins making a lot of money. By paying attention to what people are asking for (and what they're complaining about), you could find yourself in a position to create a great plugin that's successful enough that you wouldn't need anyone to hire you for anything, ever. And if people are paying you to work on projects that develop your Wordpress skills enough to get you to this point, that's even better. Doesn't hurt to think big! 
As an aside, a large portion of our industry has a problem with focusing on very narrow skill sets and ignoring the things that matter. At a previous job, where I was involved in interviewing, some of my fellow co-workers reacted very negatively to anyone whose background was mostly Java (most of our code was in C#). If you're hiring a short term contractor to solve a very specific problem, but not so much when hiring someone long term. I'd always argue that someone with experience developing complex Java apps that solve tough problems will benefit the team a lot more than someone with experience working on trivial .NET apps. In the cases where we hired such people, the argument proved true: lack of .NET/C# experience slowed them down for the first week or two, but their experience building and scaling complex applications more than made up for it over the ensuing months and years.
|
|
|
|
|
You raise valid points here. I was thinking that too: I actually do enjoy PHP a lot and I feel like especially the new version, has a lot of untapped potential. Also, coming from a .NET standpoint, it would be fun to bring some of the more advanced features that I learned in .NET to the PHP world for people as well. At the end of the day, PHP can't really go anywhere with WordPress being as big as it is, which is awesome.
However, I know that there are an awful low of hackjob-ists out there who use PHP, but that doesn't NEED to be the case. Truthfully, I'm probably going to end up specializing in WordPress plugins and .NET backend tech; and I don't feel like they are too out of reach from eachother to be calling that a jack of all trades.
|
|
|
|
|
Apple woke up their lead designer in the middle of the night to ask him about ideas for the new iPhone. The disgruntled designer told them "Jack off". The marketing department found the idea fantastic.
Source : Reddit.
|
|
|
|
|
Nish Nishant wrote: The disgruntled designer told them "Jack off".
Imagine the awesome product they would have come up with if he used the !KSS term. 
Marc
|
|
|
|
|
It would have had a Hell of a vibration!
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
|
Oh, don't talk to me about phones vibrating!
Mobile phones were perfectly good boys' toys until some idiot decided to include a vibrator in them!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Many many boys like those kind of vibrations, in one way or another!
Also, it is sad that they could reduce the size of external plugs without complaints by male users - it would explain the focus on vibrations though.
I'm treading VERY near to Soapbox material 
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
The Beach Boys even wrote a song about it, didn't they?
|
|
|
|
|
If some men woke me up while I was lying in bed the last thing I would want them to do is "Jack off".
|
|
|
|
|
So I avoided getting into an argument with the CTO about the performance of table joins. The nice thing about communication channels like Slack is that you simply don't need to reply.
His contention is that table joins are "hugely expensive", particularly for reporting. My contention is of course that a well designed database will not have this issue.
I came across this[^] interesting discussion.
But the bottom line is, I wonder why he has this attitude, particularly when his reports are dog slow, and the page request to the server times out if you ask for a report that spans more than a day (maybe a week.) Looking at the code, no wonder, because the reports seem to be generated almost entirely in Python, without leveraging table joins on the server itself at all!
Granted, there are certainly times when a very specialized report might benefit from denormalization, but for Pete's sake, these are basic transaction detail and transaction total queries.
There are so many things I disagree with the CTO about. I must have reached some level of emotional maturity before taking this job because I'm able to not get into an argument, I just say "whatever, dude" and move along.
Marc
|
|
|
|
|
To play devil's advocate, learning how the database engine and query optimizer work can be daunting to those who have never coded or haven't had to code in years/decades such as your run of the mill CTO. Like a lot of developers that I have known, they do not realize the huge performance impact of improper table design, like making the primary key a string or Guid.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
"Ohhhh! Guid == 'Good'! Let's use it!"
|
|
|
|
|
Primary Key GUID!! What an awesome idea. Wouldnt that result with forced full table scan on all type of queries?
|
|
|
|
|
I've concluded that most blanket statements are offered by those without any real knowledge. The true answer is, it depends. Tech changes, things get optimized, and so on and so forth. Even outside of that, anyone who knows anything about SQL knows two things: it depends on the data and the amount of joins in the query and it also depends on the indexes.
In my experience a join can very very expensive, but it also can be quick. They're usually the most expensive on a database that's designed like garbage.
Also, forgetting all other factors and just focusing on speed alone, sometimes it requires less bandwidth to send along the pipe one demoralized table to a client rather than several normalized ones. Not to mention the fact, dealing with drilling down on the B table for instance would require two queries at the very least avoid sending along two entire tables to the client so it can be processed that way.
The truth is simple, if the app runs like crap, and you identified the bottleneck being either the DB or the processing of what comes out of it, then he doesn't know much. The proof is in the pudding my friend. The CPU cycles don't lie.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: to send along the pipe one demoralized table
Now I'm denormalized.
Jeremy Falcon wrote: The true answer is, it depends.
Very true. It's just that he and I start with different baselines. I start with "let's assume the DB can optimize this right, given good table design, indices, etc." and if there's an issue, I look at how to optimize the query, and if that means a demoralized table then ok, but I had better have a good reason.
The CTO starts with a different baseline, on the assumption that joins are always costly. The result is pushing processing onto the script language, of all things. Not much optimization can occur there, though frankly, the code is so krufty, I imagine there actually is a ton of optimization that could happen there, even without getting into the bowels of Django.
Marc
|
|
|
|
|
Marc Clifton wrote: on the assumption that joins are always costly
I've 20 bucks that says your CTO cut his database teeth on MS Access 
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Marc Clifton wrote: Now I'm denormalized.
You're welcome. 
Marc Clifton wrote: The result is pushing processing onto the script language
I've seen this argument too, and there can be some merit to it. But, this side is almost always played by someone who simply just sucks at database administration.
All other things being equal about the only reasonable argument I can buy in regards to do some stuff in script on a client is distributing the workload rather than the server handle it all. But I seriously doubt anyone saying a blanket "joins suck" has any idea about mitigating a workload like that over a distributed process.
Jeremy Falcon
modified 9-Sep-16 13:00pm.
|
|
|
|
|
Jeremy Falcon wrote: distributing the workload rather than the server handle it all
I have been wanting to learn how to build CLR SQL function DLLs to perform the kind of work that would be a candidate for distributed processing because the SQL statement would be 20K+ lines long but I just haven't found the time yet. It has the potential liberate DBAs everywhere from developers that don't know/refuse to use the more complicated T SQL bits.
CLR in SQL tutorial
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Your argument reminds me of a time I worked for an organization that used a dBase-equivalent as their database engine. It did what it needed to do so there weren't many complaints, except when it came to certain reports. One in particular took nearly an hour to run, so it was only requested as needed. I didn't have much going on one day and I decided to poke around in the code that was in charge of that report. I looked it over and felt confident that I knew what it was doing, something the equivalent of "SELECT * FROM <table>" and then the result set was further processed (e.g., filtering, sorting) by the desktop code. I commented out a few lines of code and changed the query so that the database engine was doing all of the work rather than the desktop code. When I went to test that report, it came back almost instantly, so much so that I just assumed it failed. I did this several times and each time the report was instant and complete. I left it in place so that my supervisor could try it out when he returned. He was obviously skeptical at first, but when he saw it go, it was convincing enough that he told several users out in the business office to try it out too. Much praise was thrown our way.
Moral of the story: design the tables correctly, and let the database engine handle the workload.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
I once had a DBA tell me that views were a bad idea because they had to be rebuilt every day.
How did the guy get the job as CTO, I would presume there had to some experience with code, development or architecture. It sounds like this guy the epitomy of a manager, almost no knowledge of the subject matter and hoping to "manage" the department using his underlings knowledge, and you are not on site so the children have the most influence.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I had a similiar discussion once with our Oracle DBA. I was asked to run queries on a views he had over tables rather then the table directly as the view will not impact on the tables performance...
|
|
|
|
|
If the view was a Materialized View, then your Oracle DBA was correct.
|
|
|
|
|
If it was MS SQL Server, it wouldn't surprise me if his views all had the WITH (NOLOCK) hint on every table.
But AFAIK, Oracle rather sensibly doesn't have that option.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Mycroft Holmes wrote: I once had a DBA tell me that views were a bad idea because they had to be rebuilt every day.
Materialized Views (an Oracle thing) do have to be rebuilt at some defined interval (not necessarily every day - the timing just depends on the nature of your data). That's not to say they are a bad idea because of that. Just have to be aware of it when you design your data arch.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
