|
I have an urgent need to build a windows application and want to hire someone to do it in short time.
did anyone here hire someone from www.upwork.com from other countries?
any experience to share?
diligent hands rule....
modified 23-Nov-21 22:15pm.
|
|
|
|
|
I used to ply my trade on upwork (i think it used to be called o-desk) but I've never hired anyone else from it, FWIW.
Real programmers use butterflies
|
|
|
|
|
thanks for sharing this. I would like to give a try.
diligent hands rule....
|
|
|
|
|
Greetings Kind Regards May I inquire as no doubt you are a fine programmer why you need to hire out and out of curiosity what the requirements are - Cheerio
|
|
|
|
|
timing is a major driver
diligent hands rule....
|
|
|
|
|
"What's upwork?"
"Not much, you?"
"Wait, what?"
On a serious note, don't know the website, but I've been looking for employees myself and I can't say my experience with recruiters or recruitment platforms has been a good one.
Especially since there's such a huge shortage and chances are you'll be left with "leftovers" (the sort of dev who doesn't have a CP account  ).
As a small shop, my main barriers are costs and language.
Regarding language, I'm Dutch and my clients are Dutch, so my code is Dutch.
I've tried doing it in English in the past, but my customers have plenty of jargon and Google Translate doesn't always get it right (I once ended up with manure country instead of fattening country because the Dutch word is the same for both  ).
On top of that, it's always difficult when a customer calls and asks for X and I'll have to think of the translation and multiple devs used multiple translations...
And regarding costs, many recruiters ask for a fee that's months of salary for an employee or an hourly fee on top of a freelancer's fee that makes their hourly wage more than I can bill my (also often small) clients.
Doing anything for fixed price is pretty much impossible for such rates.
Also, don't underestimate the time and effort it costs to manage an external developer, especially when dealing with different languages and/or cultures.
And what do you want for support when the job is finished?
A freelancer is often unavailable and you'll either need to figure out the software yourself or find someone else and go through all the hassle again.
I'm interviewing two people this week who found me on a Dutch platform that doesn't bill me (yet) or developers (ever).
Hopefully one of them will want to work for a small shop and not get a better offer with much higher pay from a Sogeti, Atos Origin, Cap Gemini, etc... Because they're looking too and willing to hire pretty much anyone 
The struggle of finding good developers these days is real.
|
|
|
|
|
Sander Rossel wrote: The struggle of finding (local) good developers these days is real.
Which should cause wages to increase ( offer and demand), which is not the case.
|
|
|
|
|
I think wages are pretty much what they can be, at least for lots of companies.
My customers are now paying what they want to pay and if I ask for more they'll simply keep using Excel or paper or their old system.
In the Netherlands (and Europe?) you also have laws that prevent you from reducing salaries and firing people, so when you hire people in good economic times you may get in big trouble when times get worse.
|
|
|
|
|
Quote: laws that prevent you from reducing salaries
Does that mean programmers from the same Euro Union? What about contracting from other countries?
I am curious because I am a U.S. citizen living in Thailand doing C++ with MFC. Is there a chance of doing contract work in the Euro zone?
|
|
|
|
|
It doesn't apply to contractors, only employees.
There's a whole bunch of different laws for contractors to which many companies have found a solution: make sure there's a middle man
Strictly speaking, it's probably possible to lower salaries, but it's not easy.
But I'm not expert on these things so I can't really tell you more.
|
|
|
|
|
There is a chance, but the rates are significantly lower than in the US.
|
|
|
|
|
I prototyped most of my application and figured out all technical details already.
I just need someone to finish it quickly.
diligent hands rule....
|
|
|
|
|
Why not outsource part of the project to an experience US software contractor?
I'm just curious. I remember when I was looking for software work, I couldn't compete with off shore competition. But then again, when I read the job descriptions they were so complex and asked for the moon, that I couldn't see how these young offshore kids could even do the job.
Then I tried a recruiter, and these recruiters were clueless about software. One recruiter tried to rate my skills and said I was I was pretty low on the totem pole and that I wanted too much money, when we never really got to the money part.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
|
|
|
|
|
Did you find anyone yet?
Depending on what you need and when you need it I'd be willing to discuss doing this with JUUN Software, my own company.
As said before, you get support and everything (and I didn't say that to sell myself).
My current focus is web and cloud, but I've done plenty of WinForms back in the day (and still do from time to time).
If you're interested you can hit the email button instead of the reply button and we'll discuss things off this forum.
|
|
|
|
|
I was playing around with a super simple default WinUI3 application, trying to get an OpenFileDialog or the like of it to work....
Googling was of little help, and my desire to use WinUI3 was steadily declining...
And then there was an error message that I took the time to read (goddamn old eyes, I have to make an effort to read error messages now ) anyway it said
Quote: Consider WindowNative, InitializeWithWindow
See https://aka.ms/cswinrt/interop#windows-sdk'
And you know what? I did consider it! And followed the link!
And voila, 5 minutes later I got a C# WinUI3 application opening an OpenFileDialog! Victory! 
Now I can admit, those WinUI3 control look pretty damn nice and the application look pretty zippy, gotta migrate my work to WinUI3...
for the record, this is what the end code looked like
var filePicker = new FileOpenPicker();
filePicker.FileTypeFilter.Add("*");
InitializeWithWindow.Initialize(filePicker, WindowNative.GetWindowHandle(this));
await filePicker.PickSingleFileAsync();
modified 23-Nov-21 22:20pm.
|
|
|
|
|
So many questions.
First, why didn't they write the filepicker properly? a proper wrapper wouldn't require you to call into platform native stuff.
Second, who decided that PickSingleFile needed to be an async method and why weren't they taken out back and beaten with a stick?
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: First, why didn't they write the filepicker properly? a proper wrapper wouldn't require you to call into platform native stuff.
Hmmmm... I suspect this the UWP file picker with minimum change. it's probably not part of what was supported for WinUI3.0. More to come for WinUI3.1 around Q2 2022....
honey the codewitch wrote: Second, who decided that PickSingleFile needed to be an async method and why weren't they taken out back and beaten with a stick?
Because the code stop there for a while (until a file is picked)
--
later I try to work on my "VisualCanvas" a canvas for Visual which also does scrolling and zooming.
Turn out they don't have visual in WinUI.. mmm.. will try to do something with Shape tonight.. will see how it goes...
|
|
|
|
|
Fair enough on the first thing but regarding the second, a standard blocking method would do the same the thing.
I'm not saying it's always wrong to immediately await an asynchronous method, but when you do, you should really consider your design, and also strongly consider calling the non-asynchronous counterpart. The reason being is async isn't "free" in terms of overhead around the call, while a blocking call is (other than setting up the stack frame). And in certain cases, the latter is easier to debug as well - sometimes async methods and the debugger don't play nice when it comes to exceptions.
Real programmers use butterflies
|
|
|
|
|
Hey you know, I am just guessing here, as to their reason!... 
If you were commenting on me awaiting the file picker... ahem, while it might not be obvious in this toy sample, in the real world, there is little point to show a file picker, if not waiting for it to complete and checking what did the user pick!
Yes... exception and async can be a little trickier... but it hasn't bothered me much, mmm... I guess exception report / stack traces are the most annoying. But debugging works fine.
As to the "performance cost" this is a bloody dialog waiting on user input.. a few nanosecond more in the code is not going to help speed up user reaction with mouse and keyboard in anyway whatsoever
|
|
|
|
|
It's not so much about the performance, but additional complexity, including the background transformation the C# compiler does on your code in order to enable async. I'm a firm believer that things should be as simple as they can be and no simpler. By "free" I'm not just talking about performance, but also performance.
Frankly, I'm surprised microsoft even provided an async method for this. I think they're going a little crazy with their TAP model.
Real programmers use butterflies
|
|
|
|
|
In fact, I tried to look for a non async method, there was one and it threw an exception.
C++ has async as well since like.. 2015? pretty sure it's an async C++ method to start with!
yea async add a bit of boiler plate code.. it's done by the compiler though, it's always the same. I wouldn't worry about "unsuspected new bug" coming up...
Also, as far as I can tell, the whole point of async is to improve (unfreeze) user facing code, so show dialog async is a perfect target. If it were just for machine to machine code, async has little benefit, I reckon.
Though, to be fair and to your point, ShowDialog NOT async never froze the UI.
|
|
|
|
|
ShowDialog spins the message loop while it's displayed. I suppose in microsoft's defense they may be trying to move away from that.
Yeah C++ has async, and there it's even more important not to use it just because you can. (I'm not saying you don't have a good reason in this case - you do - but generally speaking)
The problem with async methods and that code transformation comes when someone throws an exception that isn't handled properly inside an async method implementation. Basically if you don't call SetResult or SetException (I think it's called?) on the taskresult object and instead you throw an exception the debugger won't be able to reconstruct your call stack in a way that will be helpful. Admittedly, this is most often a problem when writing your own async methods rather than consuming them, but it is easy to get wrong, especially when something you didn't expect to throw throws.
Real programmers use butterflies
modified 24-Nov-21 19:59pm.
|
|
|
|
|
I was perusing an 1861 U.S. military ordnance manual and came across this:
Quote: A man of ordinary strength exerts a force of 30 lbs. for 10 hours a day, with a velocity of 2.5 feet in a second == 4,500 lbs raised 1 foot in a minute == 1/5 the work of a horse.
So your (average then) 150 lb man was lifting 75 pounds a second and generating .20 HP for 10 hours.
(Today, "trained athletes" can do .35 HP for several hours; "healthy humans", .1 HP indefinitely)
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
|
Kind of an alternative to the article linked in the insider news, What the Future of Programming Languages Looks Like - ReadWrite. Maybe that article is right, maybe not, the things in it don't really match what I've seen, and maybe I'm wrong too. It's all tea-leaf reading anyway. You all have your ideas, let's talk about them.
- Concepts like the "borrow checker" from Rust and "nullability checker" from C# will be expanded to cover other constraints that are frequently broken by accident. "Such as what" - well who knows. Maybe we'll see refinement types being embraced, maybe linear types, maybe it will come in the form of compile-time verified asserts, or maybe we'll just continue down the path of inventing a Special Case to address each individual thing.. Whether you like these things of not, they are the trend. Don't start with "but Rice's theorem", it is well known that static analysis cannot be perfect, it doesn't have to be, it only needs to be useful.
- With more and more of the performance of modern processors being locked away behind SIMD and multi-threading, we will see the adoption of paradigms that natively handle one or both of them, for example basically writing compute shaders for the CPU. Intel ISPC is something in that direction and there will be more, because the hardware demands it. Not only x86 hardware, by the way. Even if the future holds a lot of ARM and RISCV, there will be a need to target ARM SVE and whatever RISCV calls their vector instruction set, and the (probably) dozens of small cores. Auto-vectorization doesn't really address the problem, it can only do so much when the source is written in the wrong paradigm to begin with, it can't change your inherently-serial algorithms.
- The "easy learning curve" because "everyone is going to be a programmer in the future" (from the article) is, IMO, the wrong way to look at it. I expect that lots of non-programmers will be writing some code, but they won't be interested in becoming programmers, and they won't be using general purpose programming languages. They will probably be using some expensive-but-buzzword-infested-and-horrible "business automation" packages (inflicted upon them by their boss) and their made-up proprietary languages. I feel a bit sorry for them already. It will be an extra thing that we're going to see more of, but it won't affect future languages in general, only the ones that are in that niche.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
