|
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.
|
|
|
|
|
Exactly 
|
|
|
|
|
|
That's why I said de facto standard, since ANSI C standard does not deal with implementation details. In your case we're talking about calling convection and for each platform there are several well known and understood convections (almost as if they are standardized). Any decent compiler support different calling conventions and allows you to specify it for your functions, so interoperability is not a problem. This is not the case with C++ where we have things like vtables, pointer to member, name mangling...
Tomaž Štih wrote: some architectures define ABI on C++ level
Yes, and there is a proposal to define portable ABI for C++: N4028[^]
|
|
|
|
|
I prefer C because the code is really clean an you know what it will compile into. But tt could be done in C++. The question is - do you also want to expose system services in object oriented manner or simply write a kernel using it?
Your everyday micro-kernel does following:
1) Startup code is usually written in assembler. It manages interrupts, initializes stack, vectors and BSS/DATA segments for C/C++ code, and typically ends by calling your _main function), minor changes are required here (I guess there are some C++ code startup tasks here).
2) Memory management. Operator new would have to be overloaded.
3) Task (thread) management. Maintaining thread queues (running, sleeping, waiting, suspended, etc.), basic context switching logic, algorithm to select next thread to run, and algorithms to support sync. events (this is commonly just moving threads from one queue to another).
4) IPC mechanisms. You could expose the inner kernel logic as some sort of interfaces, similar to COM vtables. And proxy each function so that it "simulates" OS mode call before executing (depending on hardware).
If you'd like to give it a go I am maintaining a tiny OS kernel for ZX Spectrum here [^]. I'd have a desire to port it to Raspberry PI for a while...
Regards,
Tomaz
|
|
|
|
|
Coming from the embedded world where C is the 800 lb gorilla, the reason for this is memory management, or lack of it. Building an OS has much in common with embedded, since it's a "bare iron" implementation. That means there no service to allocate and free memory or manage stacks and heaps. That's what the OS does.
More critical is the tradeoff between deterministic and probablistic behavior. Real time response requries deterministic response times. When an interrupt occurs it absolutely, positively has to be handled right now (want your brakes and steering to wait for the heap to be consolidated?). Inject garbage collection and heap allocation overhead, respone time become probabilistic...it may be ready on time, but no guarantee.
We think of an OS kernel in terms of threads, scheduling, maybe a filesystem, but that's what's exposed to the user. It's the internals, finding the minimal path to schedule the next task (or tasks plural for multi-core), efficiently passing inter-process messages, and optimizing I/O operations for parallel, asynchronous operation. Often the code is closely tied to the hardware, and that's where C outperforms anyting but assembler.
|
|
|
|
|
Thanks for your reply. It sounds like you know a lot about OS's, so let me ask this question:
Is the internal runtime environment of the kernel anything like what we, as application programmers, know as a "process?" Or is it some kind of amorphous, limitless environment?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
There's a micro-kernel for essential services, things like task scheduling and memory management. Essentially that's a standalone program since it's the lowest layer. Built on top of that are tasks that can be scheduled to implement the rest of the services. Task is a way to encapsulate a service. That has some security benefits by localizing references, it only runs as needed, can be swapped in a virtual system if not needed, and run multiple execution paths through the same code, important if there are several execution units (multi-core CPUs).
So the upper layers, close to the end user, are usually process based, though there are some exceptions when you get to embedded RTOS design. Response time is everything in an RTOS, which is why they exist alongside a traditional OS like LInux or Windows. In an RTOS there may not be enough resources to work through multiple layers. Remember, we're talking about a microwave oven or a sprinkler controller, not an i7 and 16GB RAM. A low level RTOS does look more like a library of method calls to a small set of services.
|
|
|
|
|
The rules for this forum state:
"For lazing about and discussing anything in a software developer's life that takes your fancy except programming questions."This topic definitely affects a software developer's life.
In 2014, the U.S. approved more than 370,000 H-1B applications. The flood of cheap foreign workers is killing compensation for software developers. In the DC region, I am seeing rates from the early 90's. In the 90's, rates were easily $40-80/hr. I think it is worse in the Seattle area. If we have a tech worker shortage, why are we at $40-80/hr 25 years later ? I want to know which candidate will shut this down ?
...thanks primarily to the ability to pay their imported workers on H-1B visas between 30 percent and 50 percent less than the prevailing American wage rate for that job.
...it's no surprise to discover that politics and business are familiar bedfellows, ...the list of the top 10 companies who apply for H-1B visas. In 2014, while six were Indian ... the rest were all American. Deloitte, IBM, Accenture, and Microsoft made up the remainder of the top 10, while Ernst & Young and Google sneaked into 11th and 12th places
Southern California Edison IT workers 'beyond furious' over H-1B replacements
Pink Slips at Disney. But First, Training Foreign Replacements
(very informative video)Protecting United States Workers[^]
...
For you South Park fans: "They took our jobs! They took der jerbs!! Durka durr!!"
modified 5-Sep-16 14:44pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
For example, I had situations where two C compilers put function arguments to the stack in the opposite order: first to last and last to first. In addition -