Recent comments in /f/programming

emma wrote

A lot of recruiters will take a shotgun approach to finding employees so they might not have actually read your profile that closely.

This. I had a recruiter from Google pester me before I was even out of high school. They'd found me through my GitHub profile which had a bunch of terrible projects that just screamed 'novice programmer'--no way I'd actually belong there.

3

hollyhoppet wrote

A lot of recruiters will take a shotgun approach to finding employees so they might not have actually read your profile that closely.

That being said you can ask them with fairly little risk if they actually mean to hire someone fresh out of college for a senior position.

You may want to uh not work for Amazon though if you value not getting an ulcer from how stressful that place can be.

5

Moonside OP wrote

Go lacks facilities for generic programming so you can't write in a sensible manner a function that operates on many different datatypes. This means you either need to write almost identical routines over and over or lose useful safety guarantees.

For example, consider a list containing strings ["lol", "lmao", "nada"] (a value of type List String) and a list containing integers [1, 2, 3] (a value of type List Integer). You wish to write two functions:

  1. length which returns the number of elements list contains.
  2. head which returns the first element of a list.

If your language supports generic programming, you can just write functions length and head that work on lists containing any type of values. But since Go doesn't, if you want to have certain safety guarantees, you need to write a version of these functions for each type. In this case, you need to implement lengthString, lengthInteger, headString and headInteger. The comment author does this kind of a process by hand from a single "master" source code file to keep himself sane, but the way he uses those Canadian Aborigine Syllabics makes it look as if Go supported generic programming.

The loss of safety guarantees (if you don't wish to implement essentially same routines n times) comes from that you can mix elements of different types together in code which fails at run time and comes crashing down. In generic programming, you can guarantee that routine outputs a value of type t if the input value was a list of values of type t, or concisely, the routine's type is List t -> t. (Your compiler can verify that your implementation abides by this rule, which is known as type safety in general.) As an another example, I can tell at a glance that a routine of type List t -> List t may

  1. drop elements from the input list,
  2. repeat some elements of the input list and
  3. rearrange elements of the input list

but can't do anything else. But if the type was List Integer -> List Integer I couldn't guarantee any of these properties. In fact a function I wrote, no matter what the parameter list is, could return the value [69] and the compiler would still say nice. Go is even worse, since the other option is interpreting all values of being the most general one, Object (or something like that). You can't even know that it's a list of Integers anymore, it could be a weird mix and you'll only know for sure when you program crashes.

Actually you can take the above reasoning even further. Suppose you have a routine of type String -> String. What can you say about it just based on its type? Hardly anything since all computation is essentially just transforming sequences of symbols into other sequences of symbols. There are as many implementations that pass the type checking as there are possible programs. But if you generalize the type into a -> a I can deduce what the routine does since there is only one possible implementation: take a parameter, do nothing with it and return it as the output. So using generics reduces code duplication, increases software safety and correctness and further helps reason about programs.

Soz that this was so long, but following Mark Twain, I just didn't have time to write anything shorter.

3

Moonside wrote

Now I can finally put my Undertale knowledge into use: she was a lot like Alphys good ending run (except Alphys was actually supercompetent in-story unlike the present person I'm talking about). Some problems:

  1. Stops communicating when she had problems
  2. the general lack of guts to just try out things
  3. All or nothing thinking when it came to implementation. I think that coders mostly implement one thing at a time, see if it works/compiles/passes the test and move on to the next thing and learn from the experience and apply it to further cases. This was totally absent. I think she tried to figure it out all in her head and if she felt any uncertainty, she just didn't try to code.
  4. Didn't habitually compile/test/see whether software worked and fix problems or annotate them if unfixed.
  5. Couldn't read official documentation Java had.

Honestly I'd say it was mostly a series of emotional issues more than anything else. You can't learn coding if you fear compiler/test feedback and trying out things and fall apart when things don't work.

2

twovests OP wrote

We're doing a lot of machine learning stuff. I think it's a lot easier for them to write code, play around, and experiment (fluidly) without doing the unfamiliar rigidity of software engineering.

You're spot on with the crappy part of programming. We're using Python, so we have so much less busy-work than other languages.

Maybe I could convince them that growing their software engineering skills will result in a better end-result for them (in terms of professional skill development) and for our sponsor (in terms of a maintainable deliverable), rather than a poorly-documented but fully-functional prototype.

3

twovests OP wrote

So the thing with this, the deliverable is only being graded on it's existence.

A corporate sponsor comes in with a project (a Real World Thing), works with students who write the code, and provides resources.

Maybe I should try getting them closer in the loop on our code? They've been trying to steer us towards good software engineering (e.g. weekly pointers like "hey go research devops and tell us about it!") but it hasn't been working.

4

musou wrote

fight the good fight IMO. my school mostly graded on correctness and program structure only. i was really undisciplined in school about things like revision control, code style, good comments. as soon as i got my first programming job i was struggling to keep up in those areas. getting them to color inside the lines now will be a benefit to them in the long run even if they hate it now as much as i did then.

4

Moonside wrote

Could you convince them that writing documentation is a nice way to procrastinate and makes the implementation part easier? I swear I solved an implementation problem (which caused no small amount of headscratching) recently just by carefully specifying the function to be implemented. By doing that I ended up describing the cases correctly which then made the implementation trivial. It was a recursive function so a botched case analysis easily leads to incomprehensible behavior.

source control, etc. as fluff, nice to have, non-productive, etc.

¡Dios mío! I'm glad that I've used source control for very low importance projects so that I can use it without any real effort when it's needed.

The crappy part of programming really is that there are so many useful tools that you have to bring together and tinker with to make them good. Like to write good unit tests you presumably ought to be specifying your functionality in good enough detail, your testing framework presumably has a few knobs to be set, then you have to make testing and documentation work with your build system, for Git you need a .gitignore file and so on, all this upfront work and busy work that makes it all easy to skirt.

3

RoundSparrow wrote (edited )

May I ask what you used for your keyboard setup?

Sure, I went with several designs because I was traveling for hundreds and hundreds of days. I'm accustomed to Lenovo/Thinkpad laptop keyboards, which are what many traveling reporters and writers prefer.

Nothing was great or bad, it depended on what size I wanted to play with. For $30 and Bluetooth, this is worth a look: https://www.amazon.com/1byone-Foldable-Bluetooth-Keyboard-Smartphone/dp/B00VRCKK1Y - I went through several different Logitech designs, etc. Odd issues can come up such as idle disconnect, but Android 5 and newer Bluetooth stack is different, so it can be device dependent.

I have an older Microsoft bluetooth travel keyboard that's light but is relatively large, but I can cram it in bags without too much trouble. It's a matter of how much typing you are doing (sometimes I do hundreds of pages of writing a week). When it comes to code, control keys are more significant, even basic things like copy/paste...

Note that a lot of Android apps have some troubles with certain keys on Bluetooth, cursor keys and such. Helps if you can modify the app you need to make it work. Although you are mostly talking classic Linux shell, so most of those issues are known and solutions are a search engine away.

2