|
What are your tips for showcasing Back-End Dev. work? Especially work where I only did the back-end. Front-End is easy: You just show them the website or photos of it, which illustrate the UX/Photo/CSS/HTML work... However, with me doing BACK-END dev, the site can look like ass but my work is actually quality work (making it more secure, faster performance, scaled, designing the DB, etc...) because I only did the back-end of things...
Not to mention, clients who view my LinkedIn and other Portfolios may not understand or want to understand the actual coding part. Front-End appears at first to lend itself to easier marketing techniques due to this, but I am sure there are workarounds for this that I haven't thought of. I am open to suggestions! Thanks!
|
|
|
|
|
If you are able to, throw the work on github. Then in the readme file on github write a high level outline of what the code itself is/does that is fancy with little snippets and why it is quality code/what the current "normal" way of achieving the functionality you've implemented on the backend is, then why the way you went about it is better.
This way those that want to dig into your repository and see all of your code can do so while others who are satisfied with the readme don't have to figure out why your backend code is fancy.
|
|
|
|
|
TheOnlyRealTodd wrote: Front-End is easy: You just show them the website or photos of it, which illustrate the UX/Photo/CSS/HTML work... Unless you're in the medical industry and it's heavily regulated and they don't want screenshots available to the public.
Jeremy Falcon
|
|
|
|
|
Or the banking industry, which makes even getting the source onto github nigh impossible in the first place. One major bank (JPMC) won't even let employees reveal they work there.
|
|
|
|
|
Coming from the standpoint of someone who's given tech interviews... I'd agree with the github or equivalent thing. But rather than release your old company's IP to the wild, why not just build a side project to showcase your skills? Then during an interview just talk about your projects and also mention that if you haven't already. That would work for me.
Jeremy Falcon
|
|
|
|
|
That makes sense and it's what I've done. Its just one of my associates is trying to get me to "talk more in plain English," some clients we may have don't even really know what back-end is, but they do actually NEED it... if that makes sense. It's hard to show a client who doesn't understand code at all what we do... For example, a MySQL site may look and fell exactly the same as a MS SQL Server site, or a MVC vs MVVM, etc...
I guess I'll just have to use plain English to explain the concepts as simple as possible.
|
|
|
|
|
For those that you want to explain your tech stack a little more in depth. In your example you could explain the cost savings of mysql vs other databases (ex: sql server). Everyone enjoys hearing how they can save money.
With MVC frameworks you could detail how it is in theory easier to maintain due to separation of concerns and in turn, easier to have other developers working on the code base.
|
|
|
|
|
For most people, tech stacks are gibberish. Only techs care about that at all.
Jeremy Falcon
|
|
|
|
|
I'd say the best bet is to know your target audience. Are you talking to an interviewer that understands tech? If so, chat about it all day long. Are you talking to a business guy that has no idea about tech? Then he won't care about XYZ at all. So your friend is right.
If it's a business type, they live and breathe on reports, reports, reports. So think metrics. Print out a report on how your backend code, reduced cost by blah blah, or made this such and such improvement. You can throw in a pie chart with that. Just put yourself in the seat of a person who is a business type of person with little tech know-how. How would you want to be sold?
Jeremy Falcon
|
|
|
|
|
I agree whole heartedly with this.
Also if you've done something that solved a problem in a neat way you could always write a blog article demonstrating it in a way that does not reveal and company specific ip.
Even if nobody reads that blog it'll be there to show a prospective employer in the future.
|
|
|
|
|
Start your own website and showcase your "Back End Work"
|
|
|
|
|
In some scenarios, queries or spreadsheets of raw, unprocessed data, and the same of processed data, the in between data, and a thorough write-up of what happens to the data, can help a bit. I've only ever shown people query results in person though, and not had to transmit said data elsewhere.
Do what thou wilt shall be the whole of the Law. - Liber AL vel Legis 1:40, Aleister Crowley
|
|
|
|
|
If you have been paid for the work and do not own it, you must not make it avaliable publicly.
|
|
|
|
|
Perhaps describe your work to a perspective customer using an analogy. Maybe a house: foundation, electrical, plumbing, etc. This way you can stress the importance of the "unseen" parts of the program using something they can visualize. You can make equivalencies about the design, ease of maintenance, ease of adding enhancements, etc. I have used this very effectively in the past. Pick your own analogy. They still won't know if your actual code is any good, but that's where references and some of the other suggestion made by others here will help.
Mike
|
|
|
|
|
Do a little video that explains in simple terms what your work is about and (without mentioning names) they way you have improved a certain project's quality.
Check this example:
Server Virtualization with VMware vSphere[^]
They show you what this product do in simple terms in a short video. It doesn't give technical details but invites you to know more.
|
|
|
|
|
Firstly, you should show some of your work. If it's not work you've done for a client then it should be work you've done at home.
Secondly, unless you're showing your work to someone who understands and also has the time to look through your code, you will need a nice UI to go with it. It adds that Jazz Factor to your work. You can then explain that you did the back end to that UI.
Finally, There are great sites out there to display you work. I'm going to recommend one (because it's mine ) codeenv.com allows you to share and show off backend work. You can share your work in an environment which allows users to instantly click and run your code. There are other websites of course which allow you to do similar stuff but I won't recommend them purely out of bias
|
|
|
|
|
Does anyone know of any modern OS kernels that are written in C++? Is there a reason they are usually written in C?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I saw this one (Thor)[^] the other day. C++ , with "some" assembly.
As for why C, I leave that to others.
TTFN - Kent
|
|
|
|
|
Richard Andrew x64 wrote: Does anyone know of any modern OS kernels that are written in C++?
There is eCos[^], for instance. And then, of course, BeOS[^] if you consider it "modern".
Richard Andrew x64 wrote: Is there a reason they are usually written in C?
Some C++ features like RTTI and exceptions are pretty hard to implement in kernel mode but most importantly pretty much all popular operating system kernels were developed before C++ was stable and widely used.
|
|
|
|
|
I think you are right. During that time C++ was still just a pre-processor too.
|
|
|
|
|
Moving onward from where Kent left you. Basically, I do a lot of Object-oriented programming and prefer it over other procedural languages. But when things have to go deep, like really deep, you should avoid distractions.
C and C++ have a basic difference, C++ has a flavor of object-oriented programming, a bit of functional programming (lambdas) and other community-suggested features. C language is free from such stuff and is very much close to Assembly language. Assembly language, as you know, is used to program the devices at the lowest level and, as per this thread[^]:
Quote: Per Brinch-Hansen once called C an "assembly language with better syntax". So, that is one of the factors why C is preferred over C++. If C++ was that much great language and better than C (which it is not in the terms of performance), even Bjarne would have started a project to port some kernel to C++. Which he did not, or that we know of. He did use C++ in many applications, started supporting the community for many projects but kernels or low-level programming was not a part of that — and all of that made sense at a higher-level of programming, in kernel development that was just garbage.
That said, now I really want to see a kernel re-written in C++ because of the amazing facts of C++, there is a try...catch block on C++, so maybe instead of halting the systems we can redirect it somewhere — redirect to termination? The processor power today doesn't care about these things, processors are powerful and intelligent enough to take care of most of issues. So, these won't be a problem in today's world. But still C++ is much more complex than C, just because of the easy features that it contains.
Finally, if you are asking why Linux kernel isn't using C++, then you would be really very much disappointed because that is never going to happen as long as Linus is managing what piece of code goes to Linux kernel. Linus Torvalds on C++[^]
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
Thanks for the terrific post!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Afzaal Ahmad Zeeshan wrote: kernel development that was just garbage.
While C++ is not used to write kernel of any major OS, it is used for other things running in kernel mode such as Windows shell and drivers.
|
|
|
|
|
C has de facto standard and stable ABI, so you can make drivers and modules work with kernel even if you used different compiler than it used to compile kernel.
C++ ABI has no de facto standard and it is widely different between different compilers so interoperability is impossible. It means you either relay on a single version of a compiler1 to do everything in kernel mode or you have to make C API to interact between different modules in which case you lose a lot of benefits of C++.
1 - sometimes you can break compatibility between binaries produced by the same compiler if you use different set of switches to compile the code
modified 2-Sep-16 19:25pm.
|
|
|
|
|
Very interesting! I guess that's why Microsoft developed COM, because they needed a way for binary compatibility between modules produced by different compilers.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|