snearch + professional_software_development   332

Peter Norvig here. I came to Python not because I thought it was a better/accept... | Hacker News
norvig on Oct 18, 2010 | parent | favorite | on: Ask PG: Lisp vs Python (2010)

Peter Norvig here. I came to Python not because I thought it was a better/acceptable/pragmatic Lisp, but because it was better pseudocode. Several students claimed that they had a hard time mapping from the pseudocode in my AI textbook to the Lisp code that Russell and I had online. So I looked for the language that was most like our pseudocode, and found that Python was the best match. Then I had to teach myself enough Python to implement the examples from the textbook. I found that Python was very nice for certain types of small problems, and had the libraries I needed to integrate with lots of other stuff, at Google and elsewhere on the net.
I think Lisp still has an edge for larger projects and for applications where the speed of the compiled code is important. But Python has the edge (with a large number of students) when the main goal is communication, not programming per se.

In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice.
Norvig_Peter  Professional_Software_Development  higher_quality  y2018  m12  d08 
december 2018 by snearch
Re: Apple f***t Entwickler doch schon seit J… | Forum - heise online
Quatsch. Noch nie von $DEVELOPER_DIR gehört? Ich paste mal aus meinen build scripts...

XC7_DIR="/Applications/Xcode.7.3.1.app/Contents/Developer"
XC8_DIR="/Applications/Xcode.8.3.3.app/Contents/Developer"
XC9_DIR="/Applications/Xcode.9.3.1.app/Contents/Developer"

export DEVELOPER_DIR="$XC9_DIR"

xcodebuild \
-derivedDataPath "$DERIVED_DATA_PATH" \
-workspace XXXXX/XXXXXXX.xcworkspace \
-scheme XXXXXX \
-configuration "Debug" \
clean | xcpretty -c >&${LOG}
Apple  XCode  mehrere_Versionen_parallel_einsetzen  Professional_Software_Development  $DEVELOPER_DIR  PROs  macOS 
june 2018 by snearch
Apple f***t Entwickler doch schon seit Jahre… | Forum - heise online
... brauchbare portable Hardware bietet Apple für Entwickler nicht an. 16 GByte sind heutzutage leider - trotz Speicherkomprimierung - weder State of the Art noch ist das für viele nicht-triviale oder auch nur Hybrid Apps genug, sondern unterstes akzeptables Limit.

Und selbst diese Geräte sind mit brauchbarer CPU und Festplatte bei Apple nicht unter 2.500 EUR zu haben. Desktop-Geräte mit ausreichend Leistung sind nicht unter 3.000 EUR zu bekommen.

Das ansich ist bereits traurig - aber noch nicht kritisch. Kritisch ist, das man beispielsweise nicht mehrere XCode-Versionen auf einem System installieren kann, um beispielsweise neue Features und SDKs zu testen und Projekte "smooth" zu migrieren - man benötigt ein weiteres System oder man muss erheblich frickeln.

Wirklich mies ist, das dank der Lizenzpolitik von Apple und den Lücken im Line-Up der Aufbau von DevOps im sinnvollen Maßstab a) sehr aufwändig ist und b) als Service in der Cloud nicht brauchbar verfügbar ist. Die derzeit beste technische Lösung - aber gleichzeitig mies dokumentierte - bietet meiner Meinung nach ausgerechnet Microsoft mit TFS Online an.

Weshalb nicht Apple?

Es würde beispielsweise bereits enorm helfen, wenn Apple ein minimales macOS Image für XCode-Build-Agents anbieten würde, welches lizenztechnisch und auch praktisch einfach mit gängigen Virtualisierungstechniken betrieben werden kann.

Das würde den Aufbau von DevOps signifikant erleichtern - sowohl im eigenen Rechenzentrum als auch in der Cloud. Vor allem könnte man auf Hardware zurückgreifen, die für den Betrieb als Build Agent besser geeignet ist, als Mac Mini, iMac & Co. und diese auch effizienter nutzen, als dies derzeit der Fall ist.

Apple ist nicht nett zu seinen Entwicklern. Die haben sich aber entweder damit abgefunden oder es müssen eben Frickelbuden sein, die unter zu viel freier Zeit leiden...

Das Entwickler ernsthaft über Mac Minis & Co. diskutieren - und damit nur über Symptome verpennter Entwicklungen und Trends im Bereich Software Development - finde ich erstaunlich. Denn von mir aus kann Apple den Mac Mini streichen - wenn es dafür endlich eine einfache, legale und supportete Möglichkeit gibt, Build Agents zu installieren. Denn mir ist am Ende scheißegal, ob der in VMWare, Virtual Box, via Xen & Co. auf einem PC Blech läuft... Im Gegenteil wäre mir das sogar lieber, weil es vieles vereinfacht und die Verfügbarkeit und Wartungsfreunlichkeit zunehmen würde...

Also vielleicht einfach mal die Diskussion ansich überdenken. Ich bin mittlerweile an einem Punkt, wo mich die Ignoranz von Apple soweit nervt, das ich gar nichts mehr für macOS und iOS entwickle. Ich fokussiere mich stattdessen mittlerweile wieder auf Windows, Linux und Android - schlicht, weil dort die Toolchain funktioniert und nicht so ein lächerlicher Scheiß wie das ist, was Apple anbietet... Denn selbst die Tools, die Apple anbieten - mit macOS Server - sind ein mieser Witz. Sorry. Kaum skalierbar, schlecht zu debuggen, praktisch nicht erweiterbar und zudem noch verbugged...

Apple sollte sich hier endlich bewegen... Und es wäre zudem eine minimale Bewegung, Entwicklern eine Möglichkeit zu öffnen, Build-Agents für macOS, iOS, tvOS, watchOS in virtuellen Umgebungen auch auf Nicht-Apple-Hardware laufen zu lassen...

Alleine der Wahnsinn, das die wenigen Hoster spezielle Halterungen entwickeln müssen und iMacs in Racks packen... Geräte mit fest verbauter Hardware, mit Bildschirm, den keiner im Rack braucht, mit nur einem Netzteil, mit nur einem Netzwerkanschluss... Was für ein kranker Wahnsinn...
Apple  criticism  Professional_Software_Development  CONs 
june 2018 by snearch
New implementation of Git in OCaml | Hacker News
yen223 10 hours ago | unvote [-]

I've been using OCaml for a couple of side projects, and I have been absolutely blown away by the amount of power this language provides. It strikes a nice balance between high-level expressiveness, while not sacrificing on performance.
I feel like OCaml is one of the programming world's best kept secret - if it had better tooling and better marketing, it could have taken over the world. I'm cautiously optimistic about ReasonML for this reason.
reply
Reason  OCaml  PROs  TOP  Inspiration  functional  Programming_Language  Profession  Professional_Software_Development  programming 
august 2017 by snearch
Talk notes: Programming and Scaling, Alan Kay 2011
r Outlook?

Ford benefited from Newton's invention of calculus, and the change of outlook Newton enabled in the West.
So an outlook, a point of view, is like 80 more IQ points!
Kay thinks CS in the USA is dead because of limited outlook.
...
Cicero: He who only knows his own generation remains forever a child.
...
Look deliberately in the past you don't know.
Kay_Alan  scaling  Professional_Software_Development  citations  change_of_outlook_+80_IQ_points  Cicero  Lernherausforderung  Arbeitstechniken 
november 2016 by snearch
Good Software Takes Ten Years. Get Used To it. - Joel on Software
Make a ten year plan. Make sure you can survive for 10 years, because the software products that bring in a billion dollars a year all took that long. Don't get too hung up on your version 1 and don't think, for a minute, that you have any hope of reaching large markets with your first version. Good software, like wine, takes time.
Business  Professional_Software_Development  IT  Software  Product  TOP  Inspiration  Erfolgsprinzip  higher_quality 
may 2016 by snearch
Lob der Langsamkeit | Technology Review
"Wenn man heute über die CeBIT geht, da kommt man schon ins Staunen", sagt Wirth, der wenig später über den "Digitalen Wandel aus der Sicht der Wissenschaft" sprechen soll. "Aber ich bin sicher, es wäre möglich rascher und sicherer zu Fortschritt zu gelangen, als wir das heute tun", ergänzt er. "Wenn man sich nur Zeit ließe, in Ruhe nachzudenken, und die Dinge wirklich zu Ende zu konstruieren." Die aber werde den jungen Software-Entwicklern heute nicht mehr gelassen, klagt Wirth. "Alles dreht sich nur noch ums Geld".
...
Dabei ist das alles eigentlich ganz logisch: Wer wenig Aufwand in die Entwicklung steckt, muss später mehr Aufwand bei der Fehler-Behebung betreiben. Das kostet Geld. Wer das nicht ausgeben will, muss also vorher mehr Aufwand treiben. Programmieren sei dazu da, "Disziplin in das Denken zu bringen", sagt Wirth. "Eine gute Programmiersprache muss einen dazu zwingen, jede unnötige Kompliziertheit zu vermeiden. Denn nur wenn Sie ein System überblicken können, können sie es auch wirklich beherrschen".
Wirth_Niklaus  Professional_Software_Development  higher_quality 
march 2016 by snearch
How to build stable systems — Medium
You build your system as a 12 factor app.

Your system is a flat set of modules with loose coupling. Each module have one responsibility and manages that for the rest of the software. Modules communicate loosely via a protocol, which means any party in a communication can be changed, as long as they still speak the protocol in the same way. Design protocols for future extension. Design each module for independence. Design each module so it could be ripped out and placed in another system and still work.
Avoid deep dependency hierarchies. They breed tight coupling. Avoid monster-modules and break them apart. Avoid the mess of microscopic modules as well. Always remember the power of copying a function and thus breaking a dependency. Fewer dependencies can some times be a win.
...
Picking a programming language

To get a robust system, you have to pick Erlang somewhere inside the system. No other language supports the robustness principles needed for stable operation.

If you don’t pick Erlang, you will have to reimplement the ideas of Erlang in your Weapon-of-Choice™.
...
A language can only succeed if you have a way to automatically deploy it with ease. The deployment tooling must be in place before use.
Professional_Software_Development  architecture_software  Ergonomie  Arbeitstechniken  modularisation  TOP  Inspiration  Erlang  PROs  deployment  higher_quality  y2018  m05  d26 
february 2016 by snearch
dpunkt.verlag ::
Ich musste früher öfters mal sagen, wie lange ein Projekt dauert - ich glaube, dies ist eine richtige Antwort: Ich gehe zum Maestro und frage ihn, wie lange es dauert. Er sagt: "X Monate." Die Zahl multipliziere ich mit 2,1 (i.W.: zwei Komma eins). So lange dauert es.

Ein Maestro denkt nämlich, Zeit sei nicht Genie. Wenn er hohe Zahlen nennen muss, wird er sich schämen. Er tötet sich aber durch seine damit selbst verschuldeten Deadlines lieber selbst, bevor er sich schämen wollte. Ein Maestro denkt irrtümlich, alle Menschen programmierten mindestens halb so gut wie er selbst. Er denkt, Software eines Maestros müsse nicht getestet werden, jedenfalls kaum oder nur pro forma. Ein Maestro wird eher unbezahlte Überstunden leisten, als den Kunden übers Ohr zu hauen.

Verstehen Sie? Die Software ist für den Maestro eine Frage seiner Ehre. Deshalb 2,1 mal X mal Monate, punktum.
Freelancing  Professional_Software_Development  Projektdauer  schätzen  Dueck_Prof._Dr._Gunter 
january 2016 by snearch
Legendary Productivity And The Fear Of Modern Programming [TechCrunch] - HackerRank Blog
Just ask Jeff Dean, the famed Googler who often is referred to as the Chuck Norris of the Internet. As the 20th Googler, Dean has a laundry list of impressive achievements, including spearheading the design and implementation of the advertising serving system. Dean pushed limits by achieving great heights in the unfamiliar domain of deep learning, but he couldn’t have done it without proactively getting a collective total of 20,000 cappuccinos with his colleagues.
model  IT  Professional_Software_Development  Google  Googler  No20  Dean_Jeff  TOP  Inspiration  cappuccino  Kaffee  Treibstoff 
december 2015 by snearch
They Write the Right Stuff | Fast Company | Business + Innovation
The process can be reduced to four simple propositions:

1. The product is only as good as the plan for the product. At the on-board shuttle group, about one-third of the process of writing software happens before anyone writes a line of code. NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do — and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints. Nothing in the specs is changed without agreement and understanding from both sides. And no coder changes a single line of code without specs carefully outlining the change. Take the upgrade of the software to permit the shuttle to navigate with Global Positioning Satellites, a change that involves just 1.5% of the program, or 6,366 lines of code. The specs for that one change run 2,500 pages, a volume thicker than a phone book. The specs for the current program fill 30 volumes and run 40,000 pages.
"Our requirements are almost pseudo-code," says William R. Pruett, who manages the software project for NASA. "They say, you must do exactly this, do it exactly this way, given this condition and this circumstance."

This careful design process alone is enough to put the shuttle organization in a class by itself, says John Munson of the University of Idaho. Most organizations launch into even big projects without planning what the software must do in blueprint-like detail. So after coders have already started writing a program, the customer is busily changing its design. The result is chaotic, costly programming where code is constantly being changed and infected with errors, even as it is being designed.
"Most people choose to spend their money at the wrong end of the process," says Munson. "In the modern software environment, 80% of the cost of the software is spent after the software is written the first time — they don't get it right the first time, so they spend time flogging it. In shuttle, they do it right the first time. And they don't change the software without changing the blueprint. That's why their software is so perfect."
...
The way the process works, it not only finds errors in the software. The process finds errors in the process.
...
John Munson, a software engineer and professor of computer science at the University of Idaho, is not quite so generous. "Cave art," he says. "It's primitive. We supposedly teach computer science. There's no science here at all."
Professional_Software_Development  Qualität  Qualitätsprodukt  NASA  TOP  Inspiration  error_free_software  process  Erfolgsprinzip  print!!!  no_computer_science  criticism  higher_quality 
october 2015 by snearch
How do you avoid burnout as a programmer? - Quora
Mike Preston, Former Senior Infrastructure Engineer at Synety
498 Views
Get ample sleep. Eat healthy. Learn things that interest you. Don't take your stresses home with you. Do something other than computers in your downtime. Go for a walk in the countryside.

Giving 100% all the time is a recipe for burnout. If you get something added to your plate (personal issues etc) then you are running on what energy reserves you have. When these are gone you will be a burnt out husk of a person. Googles 20% time and flexible working is a good way to avoid this problem. You are only running below 100% normally so you have space to deal with the addition stresses that we get from time to time.
Burnout  Profession  Professional_Software_Development  Hilfe_gegen 
september 2015 by snearch
rW_SO_Viewpoints.pdf
What’s immediately apparent is that control is re
-
ally important for Project A but almost not at all
important for Project B. This leads us to the odd
conclusion that strict control is something that
matters a lot on relatively useless projects and
much less on useful projects. It suggests that the
more you focus on control, the more likely you’re
working on a project that’s striving to deliver
something of relatively minor value.
Professional_Software_Development  Profession  Marco_Tom_de  Projektmanagement  self_criticism 
august 2015 by snearch
Erlang and distributed systems expert, gives his views on BEAM languages, Hindley–Milner… — This is not a Monad tutorial — Medium
I haven’t seen any new languages pop up recently that have grabbed my interest. On technologies, I think that microkernels are very, very interesting. Things like OSv for the JVM based languages, Mirage for OCaml and BSD Rump Kernels for the rest. I think those are going to become the fundamental building block of system orchestration in the very near future. The other thing to keep an eye on is the Nix Package manager, NixOS, and technologies like Atlas from Hashicorp. It’s not going to be too much longer before we declaratively describe out systems as well as our code. I am looking forward to that.
Prognose  Profession  Professional_Software_Development  Trend  Zukunftsmärkte  Microkernel  OSv  JVM  Mirage  OCaml  BSD  BSD_Rump_Kernel  system_orchestration  declarative  NixOS  Nix_Package_Manager  technology  Merritt  Erlang 
august 2015 by snearch
Why I'm The Best Programmer In The World*
The people who are the worst at programming are the people who refuse to accept the fact that their brains aren't equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you'll be. The more humble you are, the faster you'll improve.
Professional_Software_Development  Erfolgsprinzip  Ego  reliability 
august 2015 by snearch
My One Piece of Advice – Blake Haswell
“No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn’t convenient.”
—John Carmack (co-founder of ID Software)
Professional_Software_Development  Erfolgsprinzip  functional  programming  PROs  citations  Carmack_John  pure_function 
may 2015 by snearch
Swift in Production: Scenery | Chris Eidhof
So, when people ask me whether Swift is ready for production, for me the answer is a resounding yes. It's served us very well, and it keeps getting better, faster and easier. And the best thing: this is only the beginning of the Swift journey, if the language keeps improving at this pace, the future will be very bright indeed.
Swift  PROs  Apple  Profession  Freelancing  Professional_Software_Development 
march 2015 by snearch
Why Go? Use Racket | Hacker News
lomnakkus 1 hour ago

> Or Clojure or Erlang. Funny enough out of "functional" languages those have probably just as much (or even more) been used to develop distributed, fault tolerant systems than F# or Haskell. Just saying.

(I generally agree with the gist of your comment, I think. This just stuck out.)

I don't believe Clojure belongs in that class (as "proven" for writing reliable software), but whatever.

If you want truly reliable software and have the budget, then you just need to throw process at the problem -- it doesn't matter much which language you use. Several (if not all) the Mars landers were programmed in C -- with very few critical flaws experienced/discovered[2]. The Ericsson switches that achieved previously-unheard-of reliability were programmed in Erlang, but they used process and a huge number of engineers to achieve that. (Plus they're mostly stateless and so can just reset if they do it fast enough and don't lose important state when doing so.)

For large-scale software which has to evolve fast, I belive strong type systems do win out. It's not so much that they prevent bugs which could be caught by test suites, but having a strong type system means that you can be certain that there are a lot of tests that you actually will never have to write or, more importantly, rewrite as the system evolves.

There have been actual studies which may be of interest[1], but even if I'm on the "winning" side, I don't think I would put too much stock in the methodology/analysis of this particular study. (E.g. concluding that JavaScript suffers from few concurrency bugs relative to other languages is kind of being oblivious of the fact that JS is single-threaded (semantically) and that all the other languages in the comparison permit "real" concurrency/parallellism, and that it should thus perhaps be excluded from the category or at least treated separately.)

[1] http://macbeth.cs.ucdavis.edu/lang_study.pdf

[2] https://www.usenix.org/conference/hotdep12/workshop-program/...

(Sorry, references out of order because edited-post-facto)

reply
reliable  software  Erlang  C  process  Professional_Software_Development 
march 2015 by snearch
9 truths that computer programmers know that most people don't.
"Programming is thinking, not typing." - Casey Patton

Most of programming is spent sleeping, walking around, staring out the window, or doing anything else that helps you relax and think. Relaxing is a major key to programming, its not just sitting down and writing a thousand or more lines or code, and pushing out a program or app. We have to sit down, walk around, and just think. We need to think about how to come up with the concept, fix the issues with it, find a way to make it work, how it's going to work. Relaxation is the only way we can fix the issues the best way we can.
...


"Programming is best done "in the zone" - a (pleasant) state of mind where your focus on the task is absolute and everything seems easy. This is probably much like "the zone" for musicians and athletes." - Morgan Johansson

Ever wondered why programmers are known as nightbirds? Why we stay up all night? Because it allows us to get into the zone, it allows us to focus on one thing and not have to worry about being interupted by someone - because they are all asleep. It's a long stretch of the day where no one is up and no one is calling or trying to talk to us. It's a great time to program, and think.
...


Sleeping with a problem, can actually solve it.

If you have a problem you are told to sleep on it, forget it, put your mind at rest. But, with programmers its the go to way to solve the problem not because it gets us away from it, but because it for whatever reason helps us solve the problem with our code. Many times I have come across an issue, spent hours and hours of work on it, just trying to fix what should should be a simple problem with a simple fix. But, by going to sleep for 20minutes, an hour, six hours, twelve hours, we can wake up and immediatly know the answer to the problem.
Mind  TOP  Inspiration  Erfolgsprinzip  Profession  Professional_Software_Development  relax  eintauchen  Flow  the_zone  sleep  Unterbewusstsein  Problemlösungsstrategien 
march 2015 by snearch
Users Know: Your Job Is Not to Write Code
There’s one more important part to your job. You need to make sure that we can measure whether we’re all doing our jobs well. That means adding metrics and analytics so that we can test the effects of our changes. If you expect the code you are writing to improve user engagement (by improving the user experience in some key way), then you need to have a way to learn whether or not you succeeded. How else will you know if your job is done? Because, as I’ve mentioned, your job isn’t done until you’ve improved the product for our users.
TOP  Inspiration  Viessmann_Wangen  Professional_Software_Development  Pflichtprogramm_täglich 
february 2015 by snearch
The Mid-Career Crisis of the Perl Programmer | Hacker News
bane 2 hours ago | link

Learn to be a "programmer" not a "X programmer".

I recently sat down to learn Python a bit. Inside of a week I had useful code up and running. I'm sure it was non-idiomatic and I'll laugh from embarrassment a year from now, but screw it, it works, and real people ship.

The last code I wrote before that was in Java. I had to relearn it after a decade of non-use. Real people ship.

More recently I wrote some more Python code, it's all hacky and terrible, I can feel it, but you know what, it shipped and has kept a half-dozen people employed for another few months. Real people ship.

Most recently I had an issue to solve, not wanting to fight Python's 2.x's stupid typing issues, I hacked it out in Perl. The solution shipped. Real people ship.

GSD (get shit done) and move on. It doesn't really much matter what it's written in. It's all bits and bytes, 1s and 0s in the end.

Real people ship.

(also, don't work for free)
mehr_A_verdienen  Perl  Professional_Software_Development  Profession  Erfolgsfaktor  deep_dmain_knowledge  Lernherausforderung 
january 2015 by snearch
What blocks Ruby, Python to get Javascript V8 speed? - Stack Overflow
V8 has a team of brilliant, highly-specialized, highly-experienced (and thus highly-paid) engineers working on it, that have decades of experience (I'm talking individually – collectively it's more like centuries) in creating high-performance execution engines for dynamic OO languages. They are basically the same people who also created the Sun HotSpot JVM (among many others).
Javascript  V8  Hintergründe  Google  Java  HotSpot  Sun  JVM  Bak_Lars  Professional_Software_Development  Profession 
january 2015 by snearch
« earlier      
per page:    204080120160

related tags

$DEVELOPER_DIR  *bsd  /proc  Abwechslung  Agile_Manifesto  Airbus  Ajmani_Sameer  Alexandrescu_Andrei  algorithm  alte_Saecke  android  Ansible  Apple  apply  App_Store  Arbeitsaufwand  Arbeitsmittel  arbeitstechniken  architecture_software  Assembler  Aufwandschätzung  Aufwandsschätzung  Aufwand_schätzen  auswerten  automate_server_setup  automation  Automotive  autotools  auto_rebuild  Bak_Lars  bash  Bayesian  Bean_Zach  Beruf::Karriere  Bloom_Brandon  bm  book_recommendation  BPF  Bram_Uri  Bright_Walter  Brooks_Frederick_P.  Browsers  BSD  BSD_Rump_Kernel  Buck_Erik  build_tools  Burnout  Business  Büroausstattung  C  C#  C++  C++11  C++::modern_style  CamelCase  cappuccino  Carmack_John  cash_flow++  change_of_outlook_+80_IQ_points  check_in_everything  Chef_SW  Chrome_Browser  Cicero  citations  CMake  Cocoa  code_generation  code_review  coding_standard  Combinator  COMMON_LISP  Compilerbau  CONs  Container  copyright  Costanza_Pascal  Cox_Russ  create_new_languages  criticism  cron  cross_platfom  cross_platform  d08  d21  d23  d26  Dart  database  Dean_Jeff  debugging  debugging_strategies  declarative  deep_dmain_knowledge  default  deliberate_practice  deployment  Depressionen  Design  Design_Principles  developing  development  device_drivers  Dijkstra_Edsger_W  Disassembler  disaster  Disziplin  Dlang  Do_Not_Disturb_work  Dragon_Book  Dueck_Prof._Dr._Gunter  Eclipse  edw519  effektiv_handeln  Ego  Einsamkeit  Einstellung_geistige  eintauchen  Embedded_Systems  Encryption  Entrepreneurship  enttrotten  Entwurf  Erfolgsbedingungen  Erfolgsfaktor  Erfolgsgeheimnis  Erfolgsgeschichte  Erfolgsprinzip  Erfolgsstrategien::Eating_your_own_dogfood  Ergonomie  Erlang  error_free_software  error_handling  Existenzgründung  Existenzgründung::Software_entwickeln_und_vermarkten::Zielgruppe  F#  Fabric  Facebook  Factor  Fehlerrechnung  Feynman_Richard  File_IO  file_locking  filter  Firefox  Firefox-Lesezeichen  Flask  Flow  FLUX  Forth  Fr  framework  FreeBSD  Freelancing  Freiberuflichkeit  fsync  ftrace  FUN  functional  functrust  funny  fun_in_programming  Fuzzers  Fuzzing  games  Gedächtnis  generative_programming  Generators  Generic_Programming  git  github  Glück  GNU  Golang  Google  Googler  goto  Graphics  Graphics::Design_lernen  graphviz  Gregg_Brendan  grep  GUI  Guile  Hackers  Hamilton_James  Hammock_Driven_Development  Haskell  Hejlsberg_Anders  hft_high_frequency_trading  Hickey_Rich  high-frequency  higher_quality  Hilfe_gegen  Hintergründe  Hopper  HotSpot  how_to_write_unmaintainable_code  IBM  IDE  imposter_syndrome  Informatik  inner_resistance  Innovation  insightful  Insp.  inspiration  Installer  Intel  Intelligenz  interessant  Interesse  Interpreter  Interview  in_production  iOS  iPad  iphone  IT  Java  Javascript  JuiceSSH  JVM  Kaffee  Kaizen  Kanban  Karriere  Kay_Alan  Kernel  Kernighan_Brian  Keynote  Knuth_Donald  Komplexität  Komplexität::managen  Kreativität  Kryptografie  Kundenperspektive  kw3413  langauge_feature  large_scale_design  latex  LDAP  lernen  Lernen_lernen  Lernherausforderung  lesen_lernen  Lesezeichen-Symbolleiste  level_of_toolchain_familiarity  libraries_programmers_tools  license  Linus_Torvalds  Linux  Linux::Programmierung  LISP  logical_model_verification  Losh_Steve  LSD  LWJGL_Lightweight_Java_Game_library  Lärmschutz  m02  m05  m12  macOS  Macro  Mac_App_Store  making_robust_software  Makros  Management  managing  Marco_Tom_de  Marketing  Mars  Mars_Rover  Mars_Rovers  Mathematik  mcron  mehrere_Versionen_parallel_einsetzen  mehr_A_verdienen  Meinung  Mercurial  Merritt  Metaprogramming  Microkernel  Microsoft  Mind  Minecraft  Mirage  ML  mo  mobile  model  Modellierung  Modula-2  modularisation  Modules  Mono  Motivation  Multithreading  Musik_machen  mutation  MVC  NASA  nginx  night_owl  NixOS  Nix_Package_Manager  No20  Norvig_Peter  Notch  no_computer_science  no_license  Oberon  Objective-C  OCaml  OOP  OpenGL  Open_Source  optimization  organization  OSv  OS_X  Pair_Programming  Palm_Pre  Parent_Sean  Parrot  perf  Perl  Perl6  Pflichtprogramm_täglich  Philosophie  Photoshop  Pike_Rob  pip  PKW  pointfree  Powell_James  principles  print  print!  print!!  print!!!  Problemlösungsstrategien  process  Product  Produktivität  Profession  professional_software_development  Prognose  programming  Programming_Language  Projektdauer  Projektmanagement  Prompt  PROs  prototyping  Prozess  Prozesskompetenz  Psychologie  Pugs  Puppet  pure_function  Pygame  python  Python3  QA_Quality_Assurance  Qt  Qualität  Qualitätskontrolle  Qualitätsprodukt  Quicklisp  Racket  Rakudo  Raumfahrt  realtime  Reason  rebuild_system_automatically  reflect  Regel  Regular_Expressions  relax  reliability  reliable  research  Respekt_verdienen  REST  rewrite  risk  Ritchie_Dennis  RT  RTOS  Ruby  Ruhe  Salt  scaling  scaling_website  Scheme  Schäfer_Jorgen  schätzen  SCons  scrum  Security  Selbstorganisation  Selbständigkeit  self_criticism  separater_Raum_mit_Tür  SFML_Simple_Fast_Multimedia_Library  shell  Shuttleworth_Mark  Sicherheit  sleep  SOAP  software  Software_Developer  Software_Developers_Toolbox  Software_Development_Techniques  Software_Engineering  Software_Leverage  sorting  spaghetti_code  speed  spielen  Spieleprogrammierung  Spolsky_Joel  Sprachentwurf  SQL  SQLite  SSH  Startup  state_machine  static_typing  Statistik  Stepanov_Alexander  STL  strace  Stripping_kernel/uboot_source_to_10%_for_code_reading  Stroustrup_Bjarne  Style  Sun  Swift  SWIG  SW_Design  SW_development_practices  SW_Entwicklung_lernen  SW_Modellierung  SYPROs  systemd  System_Administration  system_orchestration  System_Programming  SysV_init  tagless-staged  talloc  Taming  Tanenbaum_Andrew_S.  technology  ten_rules  ten_safety_rules  testen  testing  teuer_bezahlt  the_expression_problem  The_Programmers'_Stone  the_zone  Thompson_Ken  Tipps_und_Tricks  Tools_Software  TOP  Torvalds_Linus  touch  touch_typing  Toyota  trading  Treibstoff  Trend  typing_faster  Ubuntu  ULID  UML  underscores  uninterrupted_work_time  Unity  unit_tests  UNIX  Unterbewusstsein  Unternehmensgründung  unternehmerisch_denken_und_handeln  Urheberrecht  Usability  usage  use_case_analysis  UUID  V8  valuable_advice  vcs  Version_Control  vi  Video  Viessmann_Wangen  virtualenv  Virtual_Machines  Visual_Event  Visual_Studio_Express  vs.  waf  webapis  Webdevelopment  Webserver  webservices  website  week  Werte  Windows  Winners_&_Losers  Wirth_Niklaus  Wissenschaft  Work_Flow_Design  writing_device_drivers  Writing_exception_safe_code  writing_faster_code  XCode  XML  XMonad  XTreme_Programming  y2012  y2018  ZeroMQ  Zukunftsmärkte  zurück_zurück  _Software 

Copy this bookmark:



description:


tags: